Open Stack

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