On Thu, Jan 12, 2017 at 4:56 PM, Jay Pipes <jaypi...@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@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@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Reply via email to