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.
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?
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 <lianhao...@intel.com
<mailto: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.
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
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev