On Thu, Nov 28, 2013 at 1:00 PM, Devananda van der Veen <
devananda....@gmail.com> wrote:
>
> On Nov 25, 2013 7:13 PM, "Doug Hellmann" <doug.hellm...@dreamhost.com>
> wrote:
> >
> >
> >
> >
> > On Mon, Nov 25, 2013 at 3:56 PM, Devananda van der Veen <
> devananda....@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 <wanghaom...@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.
> >
>
> We could send all the node.properties, Getting into node.driver_info
> would expose passwords and such, so we shouldn't send that.
>
Agreed.
> >>>
> >>> 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?
> >
> >
>
> There is an API service which exposes information about unprovisioned
> servers. At the moment, it is admin-only. If you think of an end-user as
> someone using tuskar, they will likely want to know about unprovisioned
> servers.
>
OK, then some form of auditing event (similar to the instance and network
"exists" events) might make sense. I think those are a lower priority than
the standard CRUD events, though.
> >>
> >>
> >>>
> >>> 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" <lsm...@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 <lsm...@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.
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
