<div dir="ltr">On the ceilometer integration front, I think that, over the course of Icehouse, the proposed Ironic driver API for gathering metrics was fleshed out and agreed upon internally. I am hoping that work can be completed early in Juno, at which point we'll be looking to Ceilometer to start consuming it.<div>
<br></div><div>On the "where does Ironic store credentials" front, yes, I think we do need to talk at the summit about that. It might not warrant a whole session, but it seems like we need to chat with Keystone and Barbican to figure out the right place and format for secure hardware/BMC credential storage. I'm still leaning heavily towards this being natively inside Ironic to preserve the layer separation; otoh, if it is reasonable for operators to run a "private keystone" and a "public keystone" (or private/public barbican), then it may be reasonable to put the BMC credentials in there...</div>
<div><br></div><div>Regards,</div><div>Devananda</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 26, 2014 at 1:25 PM, Eoghan Glynn <span dir="ltr"><<a href="mailto:eglynn@redhat.com" target="_blank">eglynn@redhat.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=""><br>
<br>
> I haven't gotten to my email back log yet, but want to point out that I agree<br>
> with everything Robert just said. I also raised these concerns on the<br>
> original ceilometer BP, which is what gave rise to all the work in ironic<br>
> that Haomeng has been doing (on the linked ironic BP) to expose these<br>
> metrics for ceilometer to consume.<br>
<br>
</div>Thanks Devananda, so it seems like closing out the ironic work started<br>
in the icehouse BP[1] is the way to go, while on the ceilometer side<br>
we can look into consuming these notifications.<br>
<br>
If Haomeng needs further input from the ceilometer side, please shout.<br>
And if there are some non-trivial cross-cutting issues to discuss, perhaps<br>
we could consider having another joint session at the Juno summit?<br>
<div class="im HOEnZb"><br>
Cheers,<br>
Eoghan<br>
<br>
[1] <a href="https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer" target="_blank">https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer</a><br>
<br>
</div><div class="HOEnZb"><div class="h5">> Typing quickly on a mobile,<br>
> Deva<br>
> On Mar 26, 2014 11:34 AM, "Robert Collins" < <a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a> ><br>
> wrote:<br>
><br>
><br>
> On 27 March 2014 06:28, Eoghan Glynn < <a href="mailto:eglynn@redhat.com">eglynn@redhat.com</a> > wrote:<br>
> ><br>
> ><br>
> >> On 3/25/2014 1:50 PM, Matt Wagner wrote:<br>
> >> > This would argue to me that the easiest thing for Ceilometer might be<br>
> >> > to query us for IPMI stats, if the credential store is pluggable.<br>
> >> > "Fetch these bare metal statistics" doesn't seem too off-course for<br>
> >> > Ironic to me. The alternative is that Ceilometer and Ironic would both<br>
> >> > have to be configured for the same pluggable credential store.<br>
> >><br>
> >> There is already a blueprint with a proposed patch here for Ironic to do<br>
> >> the querying:<br>
> >> <a href="https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer" target="_blank">https://blueprints.launchpad.net/ironic/+spec/send-data-to-ceilometer</a> .<br>
> ><br>
> > Yes, so I guess there are two fundamentally different approaches that<br>
> > could be taken here:<br>
> ><br>
> > 1. ironic controls the cadence of IPMI polling, emitting notifications<br>
> > at whatever frequency it decides, carrying whatever level of<br>
> > detail/formatting it deems appropriate, which are then consumed by<br>
> > ceilometer which massages these provided data into usable samples<br>
> ><br>
> > 2. ceilometer acquires the IPMI credentials either via ironic or<br>
> > directly from keystone/barbican, before calling out over IPMI at<br>
> > whatever cadence it wants and transforming these raw data into<br>
> > usable samples<br>
> ><br>
> > IIUC approach #1 is envisaged by the ironic BP[1].<br>
> ><br>
> > The advantage of approach #2 OTOH is that ceilometer is in the driving<br>
> > seat as far as cadence is concerned, and the model is far more<br>
> > consistent with how we currently acquire data from the hypervisor layer<br>
> > and SNMP daemons.<br>
><br>
> The downsides of #2 are:<br>
> - more machines require access to IPMI on the servers (if a given<br>
> ceilometer is part of the deployed cloud, not part of the minimal<br>
> deployment infrastructure). This sets of security red flags in some<br>
> organisations.<br>
> - multiple machines (ceilometer *and* Ironic) talking to the same<br>
> IPMI device. IPMI has a limit on sessions, and in fact the controllers<br>
> are notoriously buggy - having multiple machines talking to one IPMI<br>
> device is a great way to exceed session limits and cause lockups.<br>
><br>
> These seem fundamental showstoppers to me.<br>
><br>
> -Rob<br>
><br>
> --<br>
> Robert Collins < <a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a> ><br>
> Distinguished Technologist<br>
> HP Converged Cloud<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>