>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 <egl...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
