On 11/19/2015 4:05 PM, Ryan Rossiter wrote:
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.
The term is 'nauseated'. To be nauseous, you nauseate others. Which I might do from time to time.
Sorry, I'm channeling one of my wives' pet peeves because I say the same thing. Sometimes just to annoy her.
But yeah, I was made physically ill from that idea.
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
One idea I had was (and maybe this would be in a separate library like you're talking about, i.e. nova-notifications), but if nova emits the notification with the version and the consumer calls into the library that translates it into a version they want, then get that transformed thing back.
However, how does the consumer know what they want or what they can handle? Do they pin a version in configuration somewhere? I could see something like how we have upgrade levels pinned in nova so newer conductor can backlevel things for older computes.
I was also thinking about microversions and novaclient, but in that case novaclient knows what max microversion it can handle and only requests up to that version, and then nova-api handles the compat work. In the case of notifications, nova is just broadcasting those so it's not doing any compat work, but it's the only thing that knows *how* to do the compat work...
So yeah, I'm lost. -- 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
