Open Stack

On Mon, Nov 18, 2013 at 12:58 PM, Devananda van der Veen <
devananda.vdv at gmail.com> wrote:

>
> 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.
>

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131118/153fa8b7/attachment.html>