Open Stack

On Fri, Jul 5, 2013 at 11:45 AM, Jay Pipes <jaypipes at 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: chungg at ca.ibm.com
>>
>>
>> ______________________________**_________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.**org <OpenStack-dev at 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 at lists.openstack.**org <OpenStack-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130705/bd55fa4f/attachment.html>