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.
-Sean
--
Sean Dague
http://dague.net
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
