Open Stack

From my perspective, the requirement is to be able to have a consistent and predictable format for notifications that are being sent from all services. This means:
1. a set of required fields that all events contain and have consistent meaning
2. a set of optional fields, you don’t have to include these but if you do then you follow the same format and meaning
3. versioning of events: version is updated whenever the required fields are changed. managing optional fields can be done via a specification

Discovery of events would be interesting from an automated testing perspective, but I am not sure how effective this would be for an application actually consuming the event.s
Not sure how you would use enumerating the consumption of events



On Jul 10, 2014, at 2:48 AM, Eoghan Glynn <eglynn at redhat.com> wrote:

> 
> TL;DR: do we need to stabilize notifications behind a versioned
>       and discoverable contract?
> 
> Folks,
> 
> One of the issues that has been raised in the recent discussions with
> the QA team about branchless Tempest relates to some legacy defects
> in the OpenStack notification system.
> 
> Now, I don't personally subscribe to the PoV that ceilometer, or
> indeed any other consumer of these notifications (e.g. StackTach), was
> at fault for going ahead and depending on this pre-existing mechanism
> without first fixing it.
> 
> But be that as it may, we have a shortcoming here that needs to be
> called out explicitly, and possible solutions explored.
> 
> In many ways it's akin to the un-versioned RPC that existed in nova
> before the versioned-rpc-apis BP[1] was landed back in Folsom IIRC,
> except that notification consumers tend to be at arms-length from the
> producer, and the effect of a notification is generally more advisory
> than actionable.
> 
> A great outcome would include some or all of the following:
> 
> 1. more complete in-tree test coverage of notification logic on the
>    producer side
> 
> 2. versioned notification payloads to protect consumers from breaking
>    changes in payload format
> 
> 3. external discoverability of which event types a service is emitting
> 
> 4. external discoverability of which event types a service is consuming
> 
> If you're thinking that sounds like a substantial chunk of cross-project
> work & co-ordination, you'd be right :)
> 
> So the purpose of this thread is simply to get a read on the appetite
> in the community for such an effort. At the least it would require:
> 
> * trashing out the details in say a cross-project-track session at
>   the K* summit
> 
> * buy-in from the producer-side projects (nova, glance, cinder etc.)
>   in terms of stepping up to make the changes
> 
> * acquiescence from non-integrated projects that currently consume
>   these notifications
> 
>   (we shouldn't, as good citizens, simply pull the rug out from under
>   projects such as StackTach without discussion upfront)
> 
> * dunno if the TC would need to give their imprimatur to such an
>   approach, or whether we could simply self-organize and get it done
>   without the need for governance resolutions etc.
> 
> Any opinions on how desirable or necessary this is, and how the
> detailed mechanics might work, would be welcome.
> 
> Apologies BTW if this has already been discussed and rejected as
> unworkable. I see a stalled versioned-notifications BP[2] and some
> references to the CADF versioning scheme in the LP fossil-record.
> Also an inconclusive ML thread from 2012[3], and a related grizzly
> summit design session[4], but it's unclear to me whether these
> aspirations got much traction in the end.
> 
> Cheers,
> Eoghan
> 
> [1] https://blueprints.launchpad.net/nova/+spec/versioned-rpc-apis
> [2] https://blueprints.launchpad.net/nova/+spec/versioned-notifications
> [3] http://osdir.com/ml/openstack/2012-10/msg00003.html
> [4] https://etherpad.openstack.org/p/grizzly-common-messaging
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev