Open Stack

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