[openstack-dev] Treating notifications as a contract

Sandy Walsh sandy.walsh at RACKSPACE.COM
Wed Sep 3 13:50:46 UTC 2014


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?

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



More information about the OpenStack-dev mailing list