On Mon, Nov 18, 2013 at 1:35 PM, Ladislav Smola <[email protected]> wrote:
> Hello. I have a couple of additional questions. > > 1. What about IPMI data that we want to get by polling. E.g. temperatures, > etc. Will the Ironic be polling these kind of > data and send them directly to collector(or agent)? Not sure if this > belongs to Ironic. It would have to support some > pluggable architecture for vendor specific pollsters like Ceilometer. > The ceilometer and ironic teams will need to collaborate to ensure the desired data is being collected. > > 2. I've seen in the etherpad that the SNMP agent(pollster) will be also > part of the Ironic(running next to conductor). Is it true? > Or that will be placed in Ceilometer central agent? > Good question. Doug > > > Thanks for response. > Ladislav > > > > On 11/18/2013 06:25 PM, Devananda van der Veen 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 <[email protected]>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. > > >> >> 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. > > >> >> 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. > > 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. > > Regards, > Devananda > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
