Jump to: navigation, search

Difference between revisions of "GenericHostStateSpec"

(Summary)
(add link)
 
(9 intermediate revisions by one other user not shown)
Line 1: Line 1:
  
 
== Summary ==
 
== Summary ==
This blueprint addresses an issue that there are multiple sources for the nova scheduler to make scheduling decision. This blueprint is needed because we do not want the Scheduler to be dependent on Ceilometer. Such a source, for example, Cinder, Ceilometer, and compute node, are referred to as metric source.
+
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 ==  
 
== 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.
+
The key design is a periodic data collector within a scheduler for each group of metrics that share the same updating interval. Such a collector represents metrics to be consumed by the scheduler as a key-value dictionary. The dictionary works as an abstraction layer between the scheduler and the metric sources, e.g., a compute node, Ceilometer, and Cinder. 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, that a number of free VCPUs to a compute node. It also is configurable how frequent each metric should be collected by this data collector. The collector finds a group of metrics with the same interval and creates a thread, which collects the metrics in the group periodically.
  
== Design ==
+
== 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),
 +
 
 +
The spec for the hostState change is also described here https://wiki.openstack.org/wiki/Nova-scheduler-HostState.

Latest revision as of 09:07, 5 July 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 periodic data collector within a scheduler for each group of metrics that share the same updating interval. Such a collector represents metrics to be consumed by the scheduler as a key-value dictionary. The dictionary works as an abstraction layer between the scheduler and the metric sources, e.g., a compute node, Ceilometer, and Cinder. 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, that a number of free VCPUs to a compute node. It also is configurable how frequent each metric should be collected by this data collector. The collector finds a group of metrics with the same interval and creates a thread, which collects the metrics in the group periodically.

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),

The spec for the hostState change is also described here https://wiki.openstack.org/wiki/Nova-scheduler-HostState.