Open Stack

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)