Jump to: navigation, search

Difference between revisions of "GenericHostStateSpec"

m (Summary)
(Resources)
Line 7: Line 7:
  
 
== Resources ==
 
== Resources ==
This blueprint is created from a discussion on the etherpad note (https://etherpad.openstack.org/ExtensibleSchedulerHostState) and first scheduler meeting(http://eavesdrop.openstack.org/meetings/scheduler/2013/scheduler.2013-04-30-15.04.html),
+
This blueprint is created from a discussion on the etherpad note (https://etherpad.openstack.org/ExtensibleSchedulerHostState) and first scheduler sub-group meeting(http://eavesdrop.openstack.org/meetings/scheduler/2013/scheduler.2013-04-30-15.04.html),

Revision as of 08:07, 6 May 2013

Summary

This blueprint aims to address two key issues. First, currently, the only source of information for host state is a compute node; nonetheless, it is important for extending scheduling capability, if the scheduler can also use information collected from other services, for example, Ceilometer and Cinder. This blueprint addresses how such a generic host state could be implemented. Second, currently, an update interval for all metrics of host state is shared; however, some metrics change at different speeds, for instance, the number of free VCPUs and CPU utilization, and should be monitored at different intervals. This blueprint is needed because we do not want the Scheduler to be dependent on Ceilometer.

Design

The key design is a key-value dictionary that works as an abstraction layer between the scheduler and the metric sources. The key within the layer should be unique across the sources. It is configurable within this layer how to map between each key to a metric source, for example, a number of free VCPUs is mapped to a compute node.

Resources

This blueprint is created from a discussion on the etherpad note (https://etherpad.openstack.org/ExtensibleSchedulerHostState) and first scheduler sub-group meeting(http://eavesdrop.openstack.org/meetings/scheduler/2013/scheduler.2013-04-30-15.04.html),