[openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduler (was: New DB column or new DB table?)
doug.hellmann at dreamhost.com
Sat Jul 20 21:24:37 UTC 2013
On Fri, Jul 19, 2013 at 6:56 AM, Sean Dague <sean at dague.net> wrote:
> On 07/18/2013 10:12 PM, Lu, Lianhao wrote:
>> Using ceilometer as the source of those metrics was discussed in the
>> nova-scheduler subgroup meeting. (see #topic extending data in host
>> state in the following link).
>> In that meeting, all agreed that ceilometer would be a great source of
>> metrics for scheduler, but many of them don't want to make the
>> ceilometer as a mandatory dependency for nova scheduler.
>> Besides, currently ceilometer doesn't have "host metrics", like the
>> cpu/network/cache utilization data of the compute node host, which
>> will affect the scheduling decision. What ceilometer has currently
>> is the "VM metrics", like cpu/network utilization of each VM instance.
> How hard would that be to add? vs. duplicating an efficient collector
> framework in Nova?
Creating a new plugin for ceilometer's compute agent is straightforward.
The tricky bit is usually collecting the data you want in the first place,
and that won't be any more or less complicated by doing it in ceilometer or
Here's the base class:
> After the nova compute node collects the "host metrics", those metrics
>> could also be fed into ceilometer framework(e.g. through a ceilometer
>> listener) for further processing, like alarming, etc.
> I think "not mandatory" for nova scheduler means different things to
> different folks. My assumption is that means without ceilometer, you just
> don't have utilization metrics, and now you are going on static info.
> This still seems like duplication of function in Nova that could be better
> handled in a different core project. It really feels like as OpenStack
> we've decided the Ceilometer is our metrics message bus, and we should
> really push metrics there when ever we can.
> Ceilometer is an integrated project for Havana, so the argument that
> someone doesn't want to run it to get an enhancement to Nova doesn't hold a
> lot of weight in my mind.
> Sean Dague
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev