On Mon, Nov 18, 2013 at 8:58 PM, Lu, Lianhao <lianhao...@intel.com> wrote:
> > Doug Hellmann wrote on 2013-11-19: > > > > On Mon, Nov 18, 2013 at 12:25 PM, Devananda van der Veen < > devananda....@gmail.com> wrote: > > > > > > Hi Lianhao Lu, > > > > I briefly summarized my recollection of that session in this > blueprint: > > > > https://blueprints.launchpad.net/ironic/+spec/add-ceilometer-agent > > > > > > I've responded to your questions inline as well. > > > > > > On Sun, Nov 17, 2013 at 10:24 PM, Lu, Lianhao < > lianhao...@intel.com> wrote: > > > > > > Hi stackers, > > > > During the summit session Expose hardware sensor (IPMI) > data > > > https://etherpad.openstack.org/p/icehouse-summit-ceilometer-hardware-sensors, > it was proposed to deploy a ceilometer agent next to > > 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 > > and ceilometer for that proposal. > > > > 1. Just double check, ironic won't provide API to get IPMI > data, right? > > > > > > > > Correct. This was generally felt to be unnecessary. > > > > > > 2. If deploying a ceilometer agent next to the ironic > conductor, how does the agent talk to the conductor? Through rpc? > > > > > > > > My understanding is that ironic-conductor will emit messages to > the ceilimeter agent, and the communication is one-way. These could > > be triggered by a periodic task, or by some other event within Ironic, > such as a change in the power state of a node. > > > > > > Cool, so this eliminates the need for a separate agent. The ceilometer > work can be done in the collector, to receive the new messages. > > > Does this means we lose the ability to specify the different polling > interval for different monitoring data, like we have in ceilometer pipeline? > It means that would need to be implemented in the ironic code that is doing the polling. Doug > > > > > 3. Does the current ironic conductor have rpc_method to > support getting generic ipmi data, i.e. let the rpc_method caller > > specifying arbitrary netfn/command to get any type of ipmi data? > > > > > > > > No, and as far as I understand, it doesn't need one. > > > > > > 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. > > > > 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 > > ceilometer agent get those node_ids to ask the ironic conductor to poll > the ipmi data? And how can the ceilometer agent extract > > 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 > > which physical node the ipmi data is coming from? > > > > This question perhaps requires a longer answer. > > > > Ironic references physical machines (nodes) internally with an > integer node_id and externally with a standard uuid. When a Nova > > 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, > > and can be passed to Ceilometer's agent. I believe that nova > instance_uuid will enable ceilometer to detect the project, user, etc. > > > > > > If ironic has those values (at least the project), and can include them > in the notification payload, that will make processing the incoming > > notifications significantly less expensive. > > > > > > Should Ironic emit messages regarding nodes which are not > provisioned? Physical machines that don't have a tenant instance on them > > 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 > > unused disks in a SAN. > > > > > > I don't think it would be useful, but if someone else does then it seems > OK to include them. > > 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. > > -Lianhao > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev