[openstack-dev] [Nova] Ceilometer vs. Nova internal metrics collector for scheduler (was: New DB column or new DB table?)

Sean Dague sean at dague.net
Fri Jul 19 10:56:02 UTC 2013

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).
> http://eavesdrop.openstack.org/meetings/scheduler/2013/scheduler.2013-04-30-15.04.log.html
> 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?

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

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

More information about the OpenStack-dev mailing list