Open Stack

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 at 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