How is this different than extra_specs used by the filter scheduler?
http://docs.openstack.org/developer/nova/devref/filter_scheduler.html

I did some very old blueprints related to heterogeneous architectures that had 
similar goals.  
https://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-types


Fully support the idea, but probably can adapt the existing functionality to 
also target metric data.
—
Sent from Mailbox for iPad

On Wed, Jul 17, 2013 at 10:56 PM, Lu, Lianhao <lianhao...@intel.com>
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
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to