Open Stack

On 04/04/2014 12:42 AM, Mike Spreitzer wrote:

> Now let us consider how to evolve the Nova API so that a server-group
> can be scheduled holistically.  That is, we want to enable the scheduler
> to look at both the group's policies and its membership, all at once,
> and make a joint decision about how to place all the servers (instances)
> in the group.  There is no agreed answer here yet, but let me suggest
> one that I hope can move this discussion forward.  The key idea is to
> first associate not just the policies but also a description of the
> group's members with the group, then get the joint scheduling decision
> made, then let the client orchestrate the actual creation of the
> servers.  This could be done with a two-step API: one step creates the
> group, given its policies and member descriptions, and in the second
> step the client makes the calls that cause the individual servers to be
> made; as before, each such call includes a reference to the group ---
> which is now associated (under the covers) with a table that lists the
> chosen placement for each server.  The server descriptions needed in the
> first step are not as extensive as the descriptions needed in the second
> step.  For example, the holistic scheduler would not care about the
> user_data of a server.  We could define a new data structure for member
> descriptions used in the first step (this would probably be a pared-down
> version of what is used in the second step).

Why does the group itself need a separate description of the group's 
members?  It seems to me that it should be sufficient to store a 
reference to the member within the group, not an actual description. 
(Since we'd be passing the group information to the scheduler at the 
same time as the instance information, it seems natural to allow 
cross-references between them.)

I would have thought that with a holistic scheduler you would pass in 
the set of resources to be scheduled.  The scheduler would determine the 
location, temporarily reserve the resources, and pass back a set of 
opaque location tokens corresponding to each resource.  Then when you go 
to create the resource you would pass in the location token and the 
scheduler would authenticate the token and schedule it as originally 
determined.

In the case of something like server groups it's really an abstraction, 
so it might make sense to create the group before doing the scheduling 
of the servers.  That way the scheduler could update the group with the 
servers that have been scheduled but not yet instantiated, in order to 
make more accurate scheduling decisions in the future.

Chris