Open Stack

On Sep 3, 2014, at 9:50 AM, Sandy Walsh <sandy.walsh at RACKSPACE.COM> wrote:

> Is there anything slated for the Paris summit around this?
> 
> I just spent nearly a week parsing Nova notifications and the pain of no schema has overtaken me. 
> 
> We're chatting with IBM about CADF and getting down to specifics on their applicability to notifications. Once I get StackTach.v3 into production I'm keen to get started on revisiting the notification format and olso.messaging support for notifications. 
> 
> Perhaps a hangout for those keenly interested in doing something about this?

Julien did start some work on it a while back, but it was shelved for other more pressing things at the time.

https://blueprints.launchpad.net/oslo.messaging/+spec/notification-structured
https://wiki.openstack.org/wiki/Oslo/blueprints/notification-structured

It would be good to start building up a set of requirements in anticipation of a cross-project or Oslo session at the summit.

Doug

> 
> Thoughts?
> -S
> 
> ________________________________________
> From: Eoghan Glynn [eglynn at redhat.com]
> Sent: Monday, July 14, 2014 8:53 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all] Treating notifications as a contract
> 
>>> So what we need to figure out is how exactly this common structure can be
>>> accommodated without reverting back to what Sandy called the "wild west"
>>> in another post.
>> 
>> I got the impression that "wild west" is what we've already got
>> (within the payload)?
> 
> Yeah, exactly, that was my interpretation too.
> 
> So basically just to ensure that the lightweight-schema/common-structure
> notion doesn't land us back not too far beyond square one (if there are
> too many degrees-of-freedom in that declaration of "a list of dicts with
> certain required fields" that you had envisaged in an earlier post).
> 
>>> For example you could write up a brief wiki walking through how an
>>> existing widely-consumed notification might look under your vision,
>>> say compute.instance.start.end. Then post a link back here as an RFC.
>>> 
>>> Or, possibly better, maybe submit up a strawman spec proposal to one
>>> of the relevant *-specs repos and invite folks to review in the usual
>>> way?
>> 
>> Would oslo-specs (as in messaging) be the right place for that?
> 
> That's a good question.
> 
> Another approach would be to hone in on the producer-side that's
> currently the heaviest user of notifications, i.e. nova, and propose
> the strawman to nova-specs given that (a) that's where much of the
> change will be needed, and (b) many of the notification patterns
> originated in nova and then were subsequently aped by other projects
> as they were spun up.
> 
>> My thinking is the right thing to do is bounce around some questions
>> here (or perhaps in a new thread if this one has gone far enough off
>> track to have dropped people) and catch up on some loose ends.
> 
> Absolutely!
> 
>> For example: It appears that CADF was designed for this sort of thing and
>> was considered at some point in the past. It would be useful to know
>> more of that story if there are any pointers.
>> 
>> My initial reaction is that CADF has the stank of enterprisey all over
>> it rather than "less is more" and "worse is better" but that's a
>> completely uninformed and thus unfair opinion.
> 
> TBH I don't know enough about CADF, but I know a man who does ;)
> 
> (gordc, I'm looking at you!)
> 
>> Another question (from elsewhere in the thread) is if it is worth, in
>> the Ironic notifications, to try and cook up something generic or to
>> just carry on with what's being used.
> 
> Well, my gut instinct is that the content of the Ironic notifications
> is perhaps on the outlier end of the spectrum compared to the more
> traditional notifications we see emitted by nova, cinder etc. So it
> may make better sense to concentrate initially on how contractizing
> these more established notifications might play out.
> 
>>> This feels like something that we should be thinking about with an eye
>>> to the K* cycle - would you agree?
>> 
>> Yup.
>> 
>> Thanks for helping to tease this all out and provide some direction on
>> where to go next.
> 
> Well thank *you* for picking up the baton on this and running with it :)
> 
> Cheers,
> Eoghan
> 
> _______________________________________________
> 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