Open Stack

On Thu, Jul 18, 2013 at 07:05:10AM -0400, Sean Dague wrote:
> On 07/17/2013 10:54 PM, Lu, Lianhao wrote:
> >Hi fellows,
> >
> >Currently we're implementing the BP https://blueprints.launchpad.net/nova/+spec/utilization-aware-scheduling. The main idea is to have an extensible plugin framework on nova-compute where every plugin can get different metrics(e.g. CPU utilization, memory cache utilization, network bandwidth, etc.) to store into the DB, and the nova-scheduler will use that data from DB for scheduling decision.
> >
> >Currently we adds a new table to store all the metric data and have nova-scheduler join loads the new table with the compute_nodes table to get all the data(https://review.openstack.org/35759). Someone is concerning about the performance penalty of the join load operation when there are many metrics data stored in the DB for every single compute node. Don suggested adding a new column in the current compute_nodes table in DB, and put all metric data into a dictionary key/value format and store the json encoded string of the dictionary into that new column in DB.
> >
> >I'm just wondering which way has less performance impact, join load with a new table with quite a lot of rows, or json encode/decode a dictionary with a lot of key/value pairs?
> >
> >Thanks,
> >-Lianhao
> 
> I'm really confused. Why are we talking about collecting host
> metrics in nova when we've got a whole project to do that in
> ceilometer? I think utilization based scheduling would be a great
> thing, but it really out to be interfacing with ceilometer to get
> that data. Storing it again in nova (or even worse collecting it a
> second time in nova) seems like the wrong direction.
> 
> I think there was an equiv patch series at the end of Grizzly that
> was pushed out for the same reasons.
> 
> If there is a reason ceilometer can't be used in this case, we
> should have that discussion here on the list. Because my initial
> reading of this blueprint and the code patches is that it partially
> duplicates ceilometer function, which we definitely don't want to
> do. Would be happy to be proved wrong on that.

IIUC, Ceilometer is currently a downstream consumer of data from Nova, but
no functionality in Nova is a consumer of data from Ceilometer. This is good
split from a security separation point of view, since the security of Nova
is self-contained in this architecture.

If Nova schedular becomes dependant on data from ceilometer, then now the
security of Nova depends on the security of Ceilometer, expanding the attack
surface. This is not good architecture IMHO.

At the same time, I hear your concerns about the potential for duplication
of stats collection functionality between Nova & Ceilometer. I don't think
we neccessarily need to remove 100% of duplication. IMHO probably the key
thing is for the virt drivers to expose a standard API for exporting the
stats, and make sure that both ceilometer & nova schedular use the same
APIs and ideally the same data feed, so we're not invoking the same APIs
twice to get the same data.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|