Open Stack

On Mon, Nov 18, 2013 at 9:40 AM, Doug Hellmann
<doug.hellmann at dreamhost.com>wrote:

>
> On Mon, Nov 18, 2013 at 12:25 PM, Devananda van der Veen <
> devananda.vdv at 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.lu at 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.

-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131118/e4f1913d/attachment.html>