Open Stack

On Nov 1, 2012, at 3:34 PM, Sean Dague wrote:

> On 11/01/2012 02:51 PM, Gabe Westmaas wrote:
> <snip
>> Definitely a big thanks Sean.
>> 
>> I think there was something else in this session we talked about that
>> wasn't captured in the ether pad (also possible it was another session).
>> We need to start thinking about notifications a bit more rigorously as
>> well.  Versioning the notifications and treating them as another
>> (readonly) API.I'm not sure if it should be included in the same set of
>> blueprints, or just done independently, but I want to make sure we don't
>> forget that thread. Seems like we need a blueprint to start versioning if
>> there are changes we want to make to the notifications format.  In
>> addition we may need a blueprint to determine some possible strategies for
>> supporting the venting of multiple notification versions.  I'm happy to
>> work on those as long as no one else has them.
> 
> Absolutely, that actually came up in the live upgrade session in the nova room, and Dan Smith was good enough to do a very big capture of that here - http://lists.openstack.org/pipermail/openstack-dev/2012-October/001969.html
> 
> Assuming there is mostly general thumbs up on these lists, and not flying fruit, we'll start putting them into launchpad tomorrow for prioritizing.
> 
> 	-Sean
> 

Yah, this would be good to see.  
My main concerns are: 

That the versioned notifications are backwards compatible with the current ones, and
that we keep to the KISS principle with notifications :-> 

I think it could be as simple as adding a 'message_version' key to the payload with a major.minor version number (and versioning independently per event_type)

I've also pondered adding a per-event_type config for driver output/filtering, similar to the python logger (which the notification system is largely patterned after).
So compute.instance.resize.* goes to a rabbit queues x and y, error notifications to syslog, and they don't use compute.instance.update, so don't even send those out. 
Such a config could also specify versions desired (1.x for compute.instance.exists, 2.x for some other, whatever is latest for the rest, etc.) 


--
	Monsyne Dragon