Open Stack

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:
>> Hi,
>> 
>> The flavor field of the Instance object is a lazy-loaded field and 
>> the
>> 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 [1] therefore 
>> instance.flavor.projects
>> will never work and result in an exceptuion: OrphanedObjectError: 
>> Cannot
>> 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 
https://blueprints.launchpad.net/nova/+spec/flavor-notifications where 
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 
>> flavor.projects
>> in the payload as well the code would need to access the projects 
>> field
>> 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 [1]. 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.

Cheers,
gibi

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109508.html

> 
> 
> Best,
> -jay
> 
> _______________________________________________
> Mailing list: 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack