Open Stack

On Fri, Jan 13, 2017 at 9:51 AM, Balazs Gibizer 
<balazs.gibizer at ericsson.com> wrote:
> 
> 
> 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

Posting to openstack-dev as it was wrongly went to the openstack list.

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
> 
> 
> _______________________________________________
> 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