On Fri, Jan 13, 2017 at 9:51 AM, Balazs Gibizer
<balazs.gibi...@ericsson.com> wrote:
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
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 : openst...@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 : openst...@lists.openstack.org
Unsubscribe :
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
