On 11/23/15 at 04:43pm, Balázs Gibizer wrote:
From: Andrew Laski [mailto:and...@lascii.com]
Sent: November 23, 2015 17:03
On 11/23/15 at 08:54am, Ryan Rossiter wrote:
>
>
>On 11/23/2015 5:33 AM, John Garbutt wrote:
>>On 20 November 2015 at 09:37, Balázs Gibizer
>><balazs.gibi...@ericsson.com> wrote:
>>><snip>
>>><snip>
>>
>>There is a bit I am conflicted/worried about, and thats when we start
>>including verbatim, DB objects into the notifications. At least you
>>can now quickly detect if that blob is something compatible with your
>>current parsing code. My preference is really to keep the
>>Notifications as a totally separate object tree, but I am sure there
>>are many cases where that ends up being seemingly stupid duplicate
>>work. I am not expressing this well in text form :(
>Are you saying we don't want to be willy-nilly tossing DB objects
>across the wire? Yeah that was part of the rug-pulling of just having
>the payload contain an object. We're automatically tossing everything
>with the object then, whether or not some of that was supposed to be a
>secret. We could add some sort of property to the field like
>dont_put_me_on_the_wire=True (or I guess a notification_ready()
>function that helps an object sanitize itself?) that the notifications
>will look at to know if it puts that on the wire-serialized dict, but
>that's adding a lot more complexity and work to a pile that's already
>growing rapidly.
I don't want to be tossing db objects across the wire. But I also am not
convinced that we should be tossing the current objects over the wire either.
You make the point that there may be things in the object that shouldn't be
exposed, and I think object version bumps is another thing to watch out for.
So far the only object that has been bumped is Instance but in doing so no
notifications needed to change. I think if we just put objects into
notifications we're coupling the notification versions to db or RPC changes
unnecessarily. Some times they'll move together but other times, like
moving flavor into instance_extra, there's no reason to bump notifications.
Sanitizing existing versioned objects before putting them to the wire is not
hard to do.
You can see an example of doing it in
https://review.openstack.org/#/c/245678/8/nova/objects/service.py,cm L382.
We don't need extra effort to take care of minor version bumps because that
does not
break a well written consumer. We do have to take care of the major version
bumps
but that is a rare event and therefore can be handled one by one in a way John
suggested, by keep sending the previous major version for a while too.
That review is doing much of what I was suggesting. There is a separate
notification and payload object. The issue I have is that within the
ServiceStatusPayload the raw Service object and version is being dumped,
with the filter you point out. But I don't think that consumers really
care about tracking Service object versions and dealing with
compatibility there, it would be easier for them to track the
ServiceStatusPayload version which can remain relatively stable even if
Service is changing to adapt to db/RPC changes.
Note that I'm not against using objects for notifications and versioning, but I
picture having something like an InstanceNotification object which can
handle converting an Instance object into a suitable notification
version/format.
Converting between two object models is doable what I'm afraid of is that it
means we have to maintain two object models. Which also means If a new
field added to an internal object which needs to be in the related notification
then we have to add them in the notification model as well. So one field but
two places. That seems to be a duplication for me. I think we have to guess
which
case will be more frequent
a) adding a new field to an internal object that does not need to be added to
the
related notification. In this case having two separate models is better.
OR b) adding a new field to an internal object that needs to be added to the
related
notification. In this case having one model and a filtering mechanism is better.
>>
>>Thanks,
>>John
>>
>>>Cheers,
>>>Gibi
>>>>--
>>>>
>>>>Thanks,
>>>>
>>>>Matt Riedemann
>>>
>>>_______________________________________________________
___________________
>>>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
>>________________________________________________________
__________________
>>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
>
>--
>Thanks,
>
>Ryan Rossiter (rlrossit)
>
>
>_________________________________________________________
_________________
>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
__________________________________________________________
________________
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
__________________________________________________________________________
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
__________________________________________________________________________
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
