On 7/10/2014 3:48 AM, Eoghan Glynn 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
I didn't read all of this, but in nova-land yes we've wanted versioned
notifications for a long time because there are things we can't change
in the notification payload without that. There have been a few ML
threads in the past about this but no one has ever really stepped up to
work on it seriously from what I can tell.
--
Thanks,
Matt Riedemann
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
