[Openstack] [nova] Accessing instance.flavor.projects fails due to orphaned Flavor
balazs.gibizer at ericsson.com
Fri Jan 13 08:51:02 UTC 2017
On Thu, Jan 12, 2017 at 4:56 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> On 01/12/2017 05:31 AM, Balazs Gibizer wrote:
>> The flavor field of the Instance object is a lazy-loaded field and
>> projects field of the Flavor object is also lazy-loaded. Now it
>> seems to
>> me that when the Instance object lazy loads instance.flavor then the
>> created Flavor object is orphaned  therefore
>> will never work and result in an exceptuion: OrphanedObjectError:
>> call _load_projects on orphaned Flavor object.
>> Is the Flavor left orphaned by intention or it is a bug?
> Depends :) I would say it is intentional for the most part. Is there
> a reason why the Flavor *notification* payload needs to contain a
> list of projects associated with the flavor? My gut says that
> information isn't particularly germane to the relationship of the
> Instance to the Flavor?
The whole thing came up as part of the
the FlavorPayload was extended with flavor.projects. As the same
FlavorPayload is used in the instance.<action> notifications the
instance notification code path also needs the flavor.projects field.
>> The payload of instance.<action> notifications contains the flavor
>> related data of the instance in question and to have the
>> in the payload as well the code would need to access the projects
>> via instance.flavor.projects.
> Sure, I understand it would ease the access to the projects field in
> the notification payload packing, but is there really a reason to
> bother retrieving and sending that data each time an Instance
> notification event is made (which is quite often)?
So it is mainly there to have a single, consistent FlavorPayload used
across notifications. Sure we could include only just the flavor_id in
the instance.<action> notifications. However there was a similar
discussions how to handle delete notification . There we decided to
include the whole entity to the delete not just the uuid of the deleted
entity. There the main reasoning (besides consistency) was that a
notification consumer might want to listen only to certain notification
but and still want to get enough information to avoid the need of a
subsequent REST query. I think the same reasoning could be applied here.
> Mailing list:
> Post to : openstack at lists.openstack.org
> Unsubscribe :
More information about the Openstack