<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 5, 2013 at 11:45 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 07/04/2013 04:50 PM, Gordon Chung wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
hi Folks,<br>
<br>
just wanted to bring everyone's attention to this blueprint we have in<br>
Ceilometer:<br></div>
_<a href="https://blueprints.launchpad.net/ceilometer/+spec/support-standard-audit-formats_(detailed" target="_blank">https://blueprints.launchpad.<u></u>net/ceilometer/+spec/support-<u></u>standard-audit-formats_(<u></u>detailed</a><br>
bp:<br>
_<a href="https://wiki.openstack.org/wiki/Ceilometer/blueprints/support-standard-audit-formats#Provide_support_for_auditing_events_in_standardized_formats_" target="_blank">https://wiki.openstack.org/<u></u>wiki/Ceilometer/blueprints/<u></u>support-standard-audit-<u></u>formats#Provide_support_for_<u></u>auditing_events_in_<u></u>standardized_formats_</a>)<div class="im">
<br>
<br>
as a little background, there are many projects that use Ceilometer to<br>
track usage information for statistical usage analysis and billing.<br>
these projects are seeing similar auditing requirements which are<br>
missing currently. the above blueprint's proposal is to add support for<br>
auditing APIs access using the Distributed Mgmt. Task Force’s (DMTF)<br>
“Cloud Audit” standard (CADF). you can read further into the spec via<br>
the latest public draft here:<br>
<a href="http://dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0a_0.pdf" target="_blank">http://dmtf.org/sites/default/<u></u>files/standards/documents/<u></u>DSP0262_1.0.0a_0.pdf</a> but<br>
to highlight the standard, it is an open standard developed by multiple<br>
enterprises -- IBM, NetIQ, Microsoft, VMware, and Fujitsu to name a few.<br>
Also, the model is regulatory compliant (e.g. PCI-DSS, SoX, ISO 27017,<br>
etc.) and extensible so it should adapt to a broad range of uses.<br>
<br>
initially, we drafted this to be part of Ceilometer but as we've worked<br>
through it, we've noticed it is applicable in multiple projects. during<br>
the course of our discussions with Keystone developers to assure we were<br>
recording the correct data for audit, we found that Keystone itself had<br>
a blueprint to add notifications and log audit data for their APIs:<br></div>
_<a href="https://blueprints.launchpad.net/keystone/+spec/notifications_" target="_blank">https://blueprints.launchpad.<u></u>net/keystone/+spec/<u></u>notifications_</a>.<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Best,<br>
-jay<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
i thought i'd present this on the mailing list to gather feedback on the<br>
idea of adopting CADF and discuss possibly its inclusion in Oslo so that<br>
all the projects can use the same open standard when capturing events.<br>
<br>
cheers,<br>
<br>
gordon chung<br>
<br>
openstack, ibm software standards<br>
email: <a href="mailto:chungg@ca.ibm.com" target="_blank">chungg@ca.ibm.com</a><br>
<br>
<br></div><div class="im">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">John</div><br></div></div>