<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 8:58 PM, Lu, Lianhao <span dir="ltr"><<a href="mailto:lianhao.lu@intel.com" target="_blank">lianhao.lu@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Doug Hellmann wrote on 2013-11-19:<br>
<div class="im">><br>
> On Mon, Nov 18, 2013 at 12:25 PM, Devananda van der Veen <<a href="mailto:devananda.vdv@gmail.com">devananda.vdv@gmail.com</a>> wrote:<br>
><br>
><br>
>       Hi Lianhao Lu,<br>
><br>
>       I briefly summarized my recollection of that session in this blueprint:<br>
><br>
>       <a href="https://blueprints.launchpad.net/ironic/+spec/add-ceilometer-agent" target="_blank">https://blueprints.launchpad.net/ironic/+spec/add-ceilometer-agent</a><br>
><br>
><br>
>       I've responded to your questions inline as well.<br>
><br>
><br>
>       On Sun, Nov 17, 2013 at 10:24 PM, Lu, Lianhao <<a href="mailto:lianhao.lu@intel.com">lianhao.lu@intel.com</a>> wrote:<br>
><br>
><br>
>               Hi stackers,<br>
><br>
>               During the summit session Expose hardware sensor (IPMI) data<br>
> <a href="https://etherpad.openstack.org/p/icehouse-summit-ceilometer-hardware-sensors" target="_blank">https://etherpad.openstack.org/p/icehouse-summit-ceilometer-hardware-sensors</a>, it was proposed to deploy a ceilometer agent next to<br>

> the ironic conductor to the get the ipmi data. Here I'd like to ask some questions to figure out what's the current missing pieces in ironic<br>
> and ceilometer for that proposal.<br>
><br>
>               1. Just double check, ironic won't provide API to get IPMI data, right?<br>
><br>
><br>
><br>
>       Correct. This was generally felt to be unnecessary.<br>
><br>
><br>
>               2. If deploying a ceilometer agent next to the ironic conductor, how does the agent talk to the conductor? Through rpc?<br>
><br>
><br>
><br>
>       My understanding is that ironic-conductor will emit messages to the ceilimeter agent, and the communication is one-way. These could<br>
> be triggered by a periodic task, or by some other event within Ironic, such as a change in the power state of a node.<br>
><br>
><br>
> Cool, so this eliminates the need for a separate agent. The ceilometer work can be done in the collector, to receive the new messages.<br>
><br>
</div>Does this means we lose the ability to specify the different polling interval for different monitoring data, like we have in ceilometer pipeline?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">
It means that would need to be implemented in the ironic code that is doing the polling. </div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Doug</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
><br>
>               3. Does the current ironic conductor have rpc_method to support getting generic ipmi data, i.e. let the rpc_method caller<br>
> specifying arbitrary netfn/command to get any type of ipmi data?<br>
><br>
><br>
><br>
>       No, and as far as I understand, it doesn't need one.<br>
><br>
><br>
> It would only need that if we were going to poll for the data, but if ironic is emitting notifications then we don't have to do that.<br>
><br>
>               4. I believe the ironic conductor uses some kind of node_id to associate the bmc with its credentials, right? If so, how can the<br>
> ceilometer agent get those node_ids to ask the ironic conductor to poll the ipmi data? And how can the ceilometer agent extract<br>
> meaningful information from that node_id to set those fields in the ceilometer Sample(e.g. recource_id, project_id, user_id, etc.) to identify<br>
> which physical node the ipmi data is coming from?<br>
><br>
>       This question perhaps requires a longer answer.<br>
><br>
>       Ironic references physical machines (nodes) internally with an integer node_id and externally with a standard uuid. When a Nova<br>
> instance is created, it will be associated to a node, that node will have a reference to the nova instance_uuid which is exposed in our API,<br>
> and can be passed to Ceilometer's agent. I believe that nova instance_uuid will enable ceilometer to detect the project, user, etc.<br>
><br>
><br>
> If ironic has those values (at least the project), and can include them in the notification payload, that will make processing the incoming<br>
> notifications significantly less expensive.<br>
><br>
><br>
>       Should Ironic emit messages regarding nodes which are not provisioned? Physical machines that don't have a tenant instance on them<br>
> are not associated to any project, user, tenant, quota, etc, so I suspect that we shouldn't notify about them. It would be like tracking the<br>
> unused disks in a SAN.<br>
><br>
><br>
> I don't think it would be useful, but if someone else does then it seems OK to include them.<br>
<br>
</div>I think it'd better for Ironic to emit those data in case some users want to collect them, at least Ironic should have a configuration setting to emit those kind of data.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Lianhao<br>
</font></span><div class="HOEnZb"><div class="h5"><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></div>