On Mon, Nov 18, 2013 at 12:58 PM, Devananda van der Veen < devananda....@gmail.com> wrote:
> > On Mon, Nov 18, 2013 at 9:40 AM, Doug Hellmann < > doug.hellm...@dreamhost.com> wrote: > >> >> 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. >> >> >> >>> >>> >>>> >>>> 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. >> > > We can take a look as we get closer to completing this. Ironic doesn't > know anything about projects today, but we may be able to pass the > project_id in from Nova and cache it as a node property for the duration of > the instance, if that's an important optimization. > That would be good. The alternative is having to do the lookup every time an event comes in on the ceilometer side (with some suitable caching, but still, ew). Doug > > -D > > _______________________________________________ > 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