Open Stack

On Mon, Nov 25, 2013 at 3:56 PM, Devananda van der Veen <
devananda.vdv at gmail.com> wrote:

> Hi!
>
> Very good questions. I think most of them are directed towards the
> Ceilometer team, but I have answered a few bits inline.
>
>
> On Mon, Nov 25, 2013 at 7:24 AM, wanghaomeng <wanghaomeng at 163.com> wrote:
>
>>
>> Hello all:
>>
>> Basically, I understand the solution is - Our Ironic will implement an
>> IPMI driver
>>
>
> We will need to add a new interface -- for example,
> ironic.drivers.base.BaseDriver:sensor and the corresponding
> ironic.drivers.base.SensorInterface class, then implement this interface as
> ironic.drivers.modules.ipmitool:IPMISensor
>
> We also need to define the methods this interface supports and what the
> return data type is for each method. I imagine it may be something like:
> - SensorInterface.list_available_sensors(node) returns a list of sensor
> names for that node
> - SensorInterface.get_measurements(node, list_of_sensor_names) returns a
> dict of dicts, eg, { 'sensor_1': {'key': 'value'}, 'sensor_2': ...}
>
>
>> (extendable framework for more drivers) to collect hardware sensor
>> data(cpu temp, fan speed, volts, etc) via IPMI protocol from hardware
>> server node, and emit the AMQP message to Ceilometer Collector,
>> Ceilometer have the framework to handle the valid sample message and save
>> to the database for data retrieving by consumer.
>>
>> Now, how do you think if we should clearly define the *interface & data
>> model *specifications between Ironic and Ceilometer to enable IPMI data
>> collecting, then our two team can start the coding together?
>>
>
> I think this is just a matter of understanding Ceilometer's API so that
> Ironic can emit messages in the correct format. You've got many good
> questions for the Ceilometer team on this below.
>
>
>>
>> And I still have some concern with our interface and data model as below,
>> the spec need to be discussed and finalized:
>>
>> 1. What is the Ceilometer sample data mandatory attributes, such as
>> instance_id/tenant_id/user_id/resource_id, if they are not  optional, where
>> are these data populated, from Ironic or Ceilomter side?
>>
>
>>   *name/type/unit/volume/timestamp* - basic sample property, can be
>> populated from Ironic side as data source
>>   *user_id/project_id/resource_id* - Ironic or Ceilometer populate these
>> fields??
>>
>
Ceilometer knows nothing about resources unless it is told, so all of the
required fields have to be provided by the sender.



>   *resource_metadata - this is for Ceilometer metadata query, Ironic know
>> nothing for such resource metadata I think*
>>
>
The resource metadata depends on the resource type, but should be all of
the user-visible attributes for that object stored in the database at the
time the measurement is taken. For example, for instances we (try to) get
all of the instance attributes.


>   *source *- can we hard-code as 'hardware' as a source identifier?
>>
>
No, the source is the source of the user and project ids, not the source
of the measurement (the data source is implied by the meter name). The
default source for user and project is "openstack" to differentiate from an
add-on layer like a PaaS where there are different user or project ids.



>
>>
> Ironic can cache the user_id and project_id of the instance. These will
> not be present for unprovisioned nodes.
>
> I'm not sure what "resource_id" is in this context, perhaps the nova
> instance_uuid? If so, Ironic has that as well.
>

Do end-users know about bare metal servers before they are provisioned as
instances? Can a regular user, for example, as for the list of available
servers or find details about one by name or id?



>
>
>> 2. Not sure if our Ceilometer only accept the *signed-message*, if it is
>> case, how Ironic get the message trust for Ceilometer, and send the valid
>> message which can be accepted by Ceilometer Collector?
>>
>
I'm not sure it's appropriate for ironic to be sending messages using
ceilometer's sample format. We receive data from the other projects using
the more generic notification system, and that seems like the right tool to
use here, too. Unless the other ceilometer devs disagree?



>
>> 3. What is the Ceilometer sample data structure, and what is the min data
>> item set for the IPMI message be emitted to Collector?
>>   *name/type/unit/volume/**timestamp/source - is this min data item set?*
>>
>> 3. If the detailed data model should be defined for our IPMI data now?,
>> what is our the first version scope, how many IPMI data type we should
>> support? Here is a IPMI data sample list, I think we can support these as a
>> min set.
>>   *Temperature - System Temp/CPU Temp*
>> *  FAN Speed in rpm - FAN 1/2/3/4/A*
>> *  Volts - Vcore/3.3VCC/12V/VDIMM/5VCC/-12V/VBAT/VSB/AVCC*
>>
>
> I think that's a good starting list. We can add more later.
>
>
>>
>> 4. More specs - such as naming conversions, common constant reference
>> definitions ...
>>
>
>> These are just a draft, not the spec, correct me if I am wrong
>> understanding and add the missing aspects, we can discuss these interface
>> and data model clearly I think.
>>
>>
>> ----------------------------------------------------------
>> *Haomeng*
>> *Thanks:)*
>>
>>
>>
> Cheers,
> Devananda
>
>
>
>>
>> At 2013-11-21 16:08:00,"Ladislav Smola" <lsmola at redhat.com> wrote:
>>
>> Responses inline.
>>
>> On 11/20/2013 07:14 PM, Devananda van der Veen wrote:
>>
>> Responses inline.
>>
>>  On Wed, Nov 20, 2013 at 2:19 AM, Ladislav Smola <lsmola at redhat.com>wrote:
>>
>>> Ok, I'll try to summarize what will be done in the near future for
>>> Undercloud monitoring.
>>>
>>> 1. There will be Central agent running on the same host(hosts once the
>>> central agent horizontal scaling is finished) as Ironic
>>>
>>
>>  Ironic is meant to be run with >1 conductor service. By i-2 milestone
>> we should be able to do this, and running at least 2 conductors will be
>> recommended. When will Ceilometer be able to run with multiple agents?
>>
>>
>> Here it is described and tracked:
>> https://blueprints.launchpad.net/ceilometer/+spec/central-agent-improvement
>>
>>
>>  On a side note, it is a bit confusing to call something a "central
>> agent" if it is meant to be horizontally scaled. The ironic-conductor
>> service has been designed to scale out in a similar way to nova-conductor;
>> that is, there may be many of them in an AZ. I'm not sure that there is a
>> need for Ceilometer's agent to scale in exactly a 1:1 relationship with
>> ironic-conductor?
>>
>>
>> Yeah we have already talked about that. Maybe some renaming will be in
>> place later. :-) I don't think it has to be 1:1 mapping. There was only
>> requirement to have "Hardware agent" only on hosts with ironic-conductor,
>> so it has access to management network, right?
>>
>>
>>
>>> 2. It will have SNMP pollster, SNMP pollster will be able to get list of
>>> hosts and their IPs from Nova (last time I
>>>     checked it was in Nova) so it can poll them for stats. Hosts to poll
>>> can be also defined statically in config file.
>>>
>>
>>  Assuming all the undercloud images have an SNMP daemon baked in, which
>> they should, then this is fine. And yes, Nova can give you the IP addresses
>> for instances provisioned via Ironic.
>>
>>
>>
>> Yes.
>>
>>    3. It will have IPMI pollster, that will poll Ironic API, getting
>>> list of hosts and a fixed set of stats (basically everything
>>>     that we can get :-))
>>>
>>
>>  No -- I thought we just agreed that Ironic will not expose an API for
>> IPMI data. You can poll Nova to get a list of instances (that are on bare
>> metal) and you can poll Ironic to get a list of nodes (either nodes that
>> have an instance associated, or nodes that are unprovisioned) but this will
>> only give you basic information about the node (such as the MAC addresses
>> of its network ports, and whether it is on/off, etc).
>>
>>
>> Ok sorry I have misunderstood the:
>> "If there is a fixed set of information (eg, temp, fan speed, etc) that
>> ceilometer will want,let's make a list of that and add a driver interface
>> within Ironic to abstract the collection of that information from physical
>> nodes. Then, each driver will be able to implement it as necessary for that
>> vendor. Eg., an iLO driver may poll its nodes differently than a generic
>> IPMI driver, but the resulting data exported to Ceilometer should have the
>> same structure."
>>
>> I thought I've read the data will be exposed, but it will be just
>> internal Ironic abstraction, that will be polled by Ironic and send
>> directly do Ceilometer collector. So same as the point 4., right? Yeah I
>> guess this will be easier to implement.
>>
>>
>>
>>> 4. Ironic will also emit messages (basically all events regarding the
>>> hardware) and send them directly to Ceilometer collector
>>>
>>
>>  Correct. I've updated the BP:
>>
>>  https://blueprints.launchpad.net/ironic/+spec/add-ceilometer-agent
>>
>>  Let me know if that looks like a good description.
>>
>>
>> Yeah, seems great. I would maybe remove the word 'Agent', seems Ironic
>> will send it directly to Ceilometer collector, so Ironic acts as agent,
>> right?
>>
>>
>> -Devananda
>>
>>
>>
>>> Does it seems to be correct? I think that is the basic we must have to
>>> have Undercloud monitored. We can then build on that.
>>>
>>> Kind regards,
>>> Ladislav
>>>
>>>
>>
>>> On 11/20/2013 09:22 AM, Julien Danjou wrote:
>>>
>>>> On Tue, Nov 19 2013, Devananda van der Veen wrote:
>>>>
>>>> If there is a fixed set of information (eg, temp, fan speed, etc) that
>>>>> ceilometer will want,
>>>>>
>>>> Sure, we want everything.
>>>>
>>>> let's make a list of that and add a driver interface
>>>>> within Ironic to abstract the collection of that information from
>>>>> physical
>>>>> nodes. Then, each driver will be able to implement it as necessary for
>>>>> that
>>>>> vendor. Eg., an iLO driver may poll its nodes differently than a
>>>>> generic
>>>>> IPMI driver, but the resulting data exported to Ceilometer should have
>>>>> the
>>>>> same structure.
>>>>>
>>>> I like the idea.
>>>>
>>>> An SNMP agent doesn't fit within the scope of Ironic, as far as I see,
>>>>> so
>>>>> this would need to be implemented by Ceilometer.
>>>>>
>>>> We're working on adding pollster for that indeed.
>>>>
>>>> As far as where the SNMP agent would need to run, it should be on the
>>>>> same host(s) as ironic-conductor so that it has access to the
>>>>> management network (the physically-separate network for hardware
>>>>> management, IPMI, etc). We should keep the number of applications with
>>>>> direct access to that network to a minimum, however, so a thin agent
>>>>> that collects and forwards the SNMP data to the central agent would be
>>>>> preferable, in my opinion.
>>>>>
>>>> We can keep things simple by having the agent only doing that polling I
>>>> think. Building a new agent sounds like it will complicate deployment
>>>> again.
>>>>
>>>>
>>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131125/6cdd8b54/attachment.html>