This adds the description field to the FlavorPayload
for versioned notifications on flavor create/update/delete
notifications.
Part of blueprint flavor-description
Change-Id: I9a5dc8b603b5e4e0d37c59cf2749e3ffc217580c
When we destroy a flavor it's happening in the API database now.
Right after we delete the flavor, we send a delete notification
which will attempt to lazy-load projects, but because the flavor
is deleted, that will result in a FlavorNotFound from the API DB
in method _get_projects_from_db. Because of our fallback code to
the main cell DB we'll then call flavor_access_get_by_flavor_id
which returns an empty list and that's what goes into the
notification, but it's not accurate since the empty list implies
there are/were no projects with access to that flavor, when in
reality we don't know.
This handles the delete notification case by orphaning the flavor
object so that when the notification emit happens, the
NotificationPayloadBase gets an OrphanedObjectError and just
sets projects to None, which is a better representation in the
notification payload that we don't have that data.
The tests needed some work since they were not actually comparing
the payload to the flavor object before, they were comparing to
fields in the DB representation of the flavor, which doesn't
include the projects field as it's a joined column.
Change-Id: I6868efab22cf9f1eb9006589a5b62618434c3ba3
Closes-Bug: #1687012
Due to the not strict handling of uninitialized fields during
notification payload population it is possible that the emitted
notification missing some of the fields defined in the schema.
There are two problematic cases:
1) no load tirggered for lazy loaded fields. If the field was not
loaded it is not added to the payload.
2) uninitialized, not lazy loadable fields are not added to the
payload.
This patch makes sure that lazy load is triggered. If the field is
not lazy loadable and also not initialized then related payload
field will be set to None. If the payload field is not nullable
the code will fail to make sure that the inconsistency is detected.
The following changes cannot be split to different commits because
as soon as the generic schema population code is fixed every listed
notification starts behaving differently.
In some cases the availability_zone field of the Service object is left
unitialized by both the constructor and the obj_load_attr function this
caused that the availability_zone field of the service.update
notification was missing from the emitted notification payload.
The extra_specs field of the Flavor object is not lazy loadable and not
initialized in the Flavor destroy case. So the extra_specs field of the
FlavorPayload needed to be made nullable.
The projects field of the Flavor object is lazy loaded but when the
Flavor object is loaded as part of an Instance object Flavor is
orphaned and no lazy load is allowed on that Flavor object. In this
case the projects field of the FlavorPayload will be set to None to
signal that the information is not available. This also means that
the projects field of the FlavorPayload needed to be changed to
nullable.
The hosts and id fields of the Aggregate object is not initialized
during the create of the Aggregate before the aggregate.create.start
needs to be sent. Therefore these fields needs to be nullable.
Closes-Bug: #1653221
Change-Id: Ib122cd98ee0cc31938d5ff1d5c753053267a3bd4
This patch implements the versioned notifications for flavor
create and destroy.
Implement blueprint: flavor-notifications
Change-Id: Icc2169b87ffba4e7e2079076a82029156c584c6a
Matt Riedemann