Nova/CachingScheduler

This wiki page describes the experimental scheduler that is being suggested here: https://blueprints.launchpad.net/nova/+spec/caching-scheduler

How it works

We can roughly describe scheduling as:

load the current state (expensive, very expensive with current DB call)
use filters and weights to help pick a host (expensive with lots of hosts)

The caching scheduler splits this into:

in the background...
- admin configure a list of flavors, and how many "slots" for each flavor to reserve
- in a periodic task we populate the cache
- we generate a partial request_spec and run that through the existing filters and weights logic in host manager
- the save the best hosts, as picked by the filters and weights
- we try to fill all the request slots, in order
when a user requests a server...

Configuration

[caching_scheduler]

#
# Options defined in nova.scheduler.caching_scheduler
#

# Specification of the cache lists, a list of flavor_id.
# (multi valued)
#cache_list=

# Proportion by which to weight number of each flavor. If not
# defined, all our evenly weighted (multi valued)
#weights=

# Number of slots to keep for each flavor with a weight of
# one. (floating point value)
#factor=1.0

# How often to refresh the cached slots. (integer value)
#poll_period=60

Future work

We currently have blueprints to look at:

Currently this only works with a single scheduler, need to look at either:
- sharing the cache between scheduler, worker populates cache
- locking resources between schedulers (two phase commit), but still have each scheduler with their own cache
- shard hosts so each scheduler deals with a separate list of hosts
Caching by flavor is probably not always enough, we can look at a more complex cache key, at least including os_type