As of late 2015 the scheduler part of Nova (the part of OpenStack that manages compute resources) is responsible for determining on which compute nodes a set of VMs (or other compute resources) will be placed when an agent (human or otherwise) requests a set of servers.
In the future it will be responsible for scheduling in a more general fashion and will hopefully not be a part of Nova. To get it there it needs to become more tidy and contained. To make it more tidy and contained it needs to be understood. I'm new to the Nova codebase so I've gone on a little field trip through the code. These are notes from that exploration. There will likely be multiple parts. Some of this may be wrong. Please help me correct it if it is.
From a user's standpoint the scheduler is mostly a black box. The client asks for a server or servers to be created that match a set of requirements and gets back a URL where the progress of the build can be tracked. The scheduler does its job asynchronously, selecting a list of potential destinations for the requested servers in a task that is spawned during the request.
The body of the
POST to create the servers contains some
attributes (e.g. availability zones, scheduler hints, flavor choice)
that will be used to constrain the selected destinations. Details of
that specification will be described in a later post.
The HTTP API calls
create on the compute API, realized as
nova.compute.api.API.create. This validates all inputs and then
build_instances methods through a series of layers of indirection
that eventually call
An aside about the architecture of Nova may be useful here. Different types of service run as indepdendent processes which communicate using RPC driven by an AMQP message bus. The RPC API is considered private and the only stable interface is the HTTP API. At the center of the several services is a service called the conductor which, as you might expect, conducts most of the activity by acting on requests from service A and coordinating the required actions on other services, B. The conductor is the primary conduit with the storage layer.
Much, but not yet all, of this conducting happens with data encapsulated in something called versioned objects. These allow the different services in Nova to be updgraded on different timetables. The conductor can transform an object that is currently a version a target service cannot handle into a version it can (this is an oversimplification, but gets the main gist).
The HTTP API service and the scheduler service don't talk. The HTTP API service has been asked to create some instances, so it tells the conductor it needs to
build_instancesbut doesn't know it needs to schedule them. The conductor does.
The conductor manager has a scheduler client which calls
select_destinations on the scheduler itself. Unlike the earlier
build_instances, this is a synchronous call that waits
for a result. The result is an ordered lists of hosts. These hosts
are paired with the requested servers and builds of the instances
That list of hosts is constrained by
filter_properties. In the past these were separate objects. In the
evolving scheduler, these will be represented by a
object. The details of what this is for and how it is created and used
will be in the next post.