Open Stack

Let me add one more thing:

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

There really should be one more step in that flow.  Consider a create 
scenario.  In general, as the client makes the calls to create individual 
resources: some will succeed, some will fail (some in ways that make it 
clear the capacity will not be used, others not), for some the client will 
issue the request but timeout waiting for success, and for some the client 
will never even issue the call to create.  After the client has done as 
much as it will, there should be another call back to the holistic 
scheduling function to release the capacity that was planned to be used 
but the client has given up on.

Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140408/bbde27a5/attachment.html>