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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
