> > 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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
