GenericHostStateSpec

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.