Reading through [1] I started getting worries in the back of my head
about versioning these notifications. The main concern being how can the
consumer know about the versions and what's different between them?
Because these versioned notification payloads hold live nova objects,
there can be a lot of rug-pulling going on underneath these
notifications. If the payload doesn't pin itself to a certain level of
the object, a consumer can never be guaranteed the version of the
payload's object they will be receiving. I ran through a few of the
scenarios about irregular versions in the notifications subteam meeting
on Tuesday [2].
My question is.... do we care about the consumer? Or is it a case of
"the consumer is always right" so we need to make sure we hand them
super consistent, well-defined blobs across the wire? Consumers will
have no idea of nova object internals, unless they feel like `python -c
import nova`. I do think we get one piece of help from o.vo though. When
the object is serialized, it hands the version with the object. So
consumers can look at the object and say "oh, I got 1.4 I know what to
do with this". But... they will have to implement their own compat
logic. Everyone will have to implement their own compat logic.
We could expose a new API for getting the schema for a specific version
of a notification, so a consumer will know what they're getting with
their notifications. But I think that made mriedem nauseous. We could
make an oslo library that stuffs a shim in between o.vo and nova's
notifications to help out with compat/versioning, but that sounds like a
lot of work, especially because the end goal is still not clearly defined.
Thoughts?
[1] https://review.openstack.org/#/c/247024
[2]
http://eavesdrop.openstack.org/irclogs/%23openstack-meeting-alt/%23openstack-meeting-alt.2015-11-17.log.html#t2015-11-17T20:22:29
--
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
