Open Stack

> > 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!)** so i was on vacation when this thread popped up. i'll just throw a disclaimer, i didn't read the initial conversion thread... also, i just read what i typed below and ignore the fact it sounds like a sales pitch. **
CADF is definitely a well-defined open standard with contributions from multiple companies so there are a lot of use cases, case and point the daunting 100+ pg spec [1].
the purpose of CADF was to be an auditable event model to describe cloud events (basically what our notifications are in OpenStack). regarding CADF in OpenStack[2], pyCADF has now been moved under the Keystone umbrella to handle auditing.  Keystone thus far has done a great job incorporating pyCADF into their notification messages.
while the spec is quite verbose, there is a short intro to CADF events and how to define them in the pycadf docs [3]. we also did a talk at the Atlanta summit [4] (apologies for my lack of presentation skills). lastly, i know we previously had a bunch of slides describing/explaining CADF at a highlevel. i'll let ibmers find a copy to post to slideshare or the like.
> * At the micro level have versioned schema for notifications such that
> one end can declare "I am sending version X of notification
> foo.bar.Y" and the other end can effectively deal.
the event model has a mandatory typeURI field where you could define a version
> These ideas serve two different purposes: One is to ensure that
> existing notification use cases are satisfied with robustness and
> provide a contract between two endpoints. The other is to allow a
> fecund notification environment that allows and enables many
> participants.
CADF is designed to be extensible so even if a use cases is not specifically defined in spec, the model can be extended to accommodate. additionally, one of the chairs of the CADF spec is also a contributor to pyCADF so there are opportunities to shape the future of the CADF (something we did, while building pyCADF).
> 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
i'd love for OpenStack to converge on a standard (whether CADF or not). personal experience tells me it'll be difficult, but i think more and more have realised just making the 'wild west' even wilder isn't helping.
[1] http://www.dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0.pdf[2] http://www.dmtf.org/standards/cadf
[3] http://docs.openstack.org/developer/pycadf/event_concept.html[4] https://www.openstack.org/summit/openstack-summit-atlanta-2014/session-videos/presentation/an-overview-of-cloud-auditing-support-for-openstack
cheers,
gord 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140903/1715f1aa/attachment.html>