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