On Sep 3, 2014, at 9:50 AM, Sandy Walsh <[email protected]> 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 [[email protected]] > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
