On Fri, Jul 5, 2013 at 11:45 AM, Jay Pipes <jaypi...@gmail.com> wrote:
> On 07/04/2013 04:50 PM, Gordon Chung wrote: > >> hi Folks, >> >> just wanted to bring everyone's attention to this blueprint we have in >> Ceilometer: >> _https://blueprints.launchpad.**net/ceilometer/+spec/support-** >> standard-audit-formats_(**detailed<https://blueprints.launchpad.net/ceilometer/+spec/support-standard-audit-formats_(detailed> >> bp: >> _https://wiki.openstack.org/**wiki/Ceilometer/blueprints/** >> support-standard-audit-**formats#Provide_support_for_** >> auditing_events_in_**standardized_formats_<https://wiki.openstack.org/wiki/Ceilometer/blueprints/support-standard-audit-formats#Provide_support_for_auditing_events_in_standardized_formats_> >> ) >> >> >> as a little background, there are many projects that use Ceilometer to >> track usage information for statistical usage analysis and billing. >> these projects are seeing similar auditing requirements which are >> missing currently. the above blueprint's proposal is to add support for >> auditing APIs access using the Distributed Mgmt. Task Force’s (DMTF) >> “Cloud Audit” standard (CADF). you can read further into the spec via >> the latest public draft here: >> http://dmtf.org/sites/default/**files/standards/documents/** >> DSP0262_1.0.0a_0.pdf<http://dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0a_0.pdf>but >> to highlight the standard, it is an open standard developed by multiple >> enterprises -- IBM, NetIQ, Microsoft, VMware, and Fujitsu to name a few. >> Also, the model is regulatory compliant (e.g. PCI-DSS, SoX, ISO 27017, >> etc.) and extensible so it should adapt to a broad range of uses. >> >> initially, we drafted this to be part of Ceilometer but as we've worked >> through it, we've noticed it is applicable in multiple projects. during >> the course of our discussions with Keystone developers to assure we were >> recording the correct data for audit, we found that Keystone itself had >> a blueprint to add notifications and log audit data for their APIs: >> _https://blueprints.launchpad.**net/keystone/+spec/**notifications_<https://blueprints.launchpad.net/keystone/+spec/notifications_> >> . >> > > After reading the detailed spec, I don't understand why this would belong > anywhere other than Ceilometer. There's no need to push a different source > event notification format on all the other projects. All that the proposed > spec would really add is a translation middleware endpoint in the > Ceilometer REST API to translate query results from the (simpler and more > intuitive) Ceilometer resource REST API to the (more complicated but > thankfully not XML) resource results of the CADF format. > > In other words, the entire thing can be constructed as a simple piece of > Python WSGI middleware that transforms requests and responses from one > format to another. FWICT, Ceilometer already collects all of the base data > elements that are needed by CADF, and all that really would be happening is > changing the object key names for some of the elements and adding in tag > bindings for source and project. > > So, -1 on adding this to Oslo. I don't think it needs to go in there, > since I don't think other projects need it. > > Best, > -jay > > i thought i'd present this on the mailing list to gather feedback on the >> idea of adopting CADF and discuss possibly its inclusion in Oslo so that >> all the projects can use the same open standard when capturing events. >> >> cheers, >> >> gordon chung >> >> openstack, ibm software standards >> email: chu...@ca.ibm.com >> >> >> ______________________________**_________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.**org <OpenStack-dev@lists.openstack.org> >> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >> >> > > ______________________________**_________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.**org <OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > I agree with Monty and Jay on this (don't see others needing it currently, but no reason if that changes to not address the OSLO question then), but it did raise a question, are you suggesting that we should implement DMTF standards in other projects? For example SMIS in Cinder? I hope that's not the case, but thinking maybe I should ask. John
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev