Open Stack

On Mon, Nov 18, 2013 at 8:58 PM, Lu, Lianhao <lianhao.lu at intel.com> wrote:

>
> Doug Hellmann wrote on 2013-11-19:
> >
> > 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.
> >
> Does this means we lose the ability to specify the different polling
> interval for different monitoring data, like we have in ceilometer pipeline?
>

It means that would need to be implemented in the ironic code that is doing
the polling. 

Doug


>
> >
> >               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.
> >
> >
> >       Should Ironic emit messages regarding nodes which are not
> provisioned? Physical machines that don't have a tenant instance on them
> > are not associated to any project, user, tenant, quota, etc, so I
> suspect that we shouldn't notify about them. It would be like tracking the
> > unused disks in a SAN.
> >
> >
> > I don't think it would be useful, but if someone else does then it seems
> OK to include them.
>
> I think it'd better for Ironic to emit those data in case some users want
> to collect them, at least Ironic should have a configuration setting to
> emit those kind of data.
>
> -Lianhao
>
>
>
> _______________________________________________
> 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/20131119/109856af/attachment.html>