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

Yes, that pretty much sums it up.

> 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

Yes, the motivating usecase was discoverability for testing.

> Not sure how you would use enumerating the consumption of events

Ditto, though on reflection I'm thinking discoverablity of the more
downstream thing (the gathering of certain meters in ceilometer's case)
would be far more meaningful to reason over.

Cheers,
Eoghan 

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