----- Original Message ----- > Hi Stackers, > >8---------->8---------->8---------->8---------->8---------->8---------- > > Proposal > -------- > > I propose to scrap the server groups API entirely and replace it with a > simpler way to accomplish the same basic thing. > > Create two new options to nova boot: > > --near-tag <TAG> > and > --not-near-tag <TAG> > > The first would tell the scheduler to place the new VM near other VMs > having a particular "tag". The latter would tell the scheduler to place > the new VM *not* near other VMs with a particular tag.
Would we continue to grow this set of arguments in response to the addition of new policies, how much do we expect this to grow? The two most likely additions I can think of are "soft"/"best effort" versions of the current two, are there any other proposals/ideas out there - I know we're a creative bunch ;)? > What is a "tag"? Well, currently, since the Compute API doesn't have a > concept of a single string tag, the tag could be a key=value pair that > would be matched against the server extra properties. > > Once a real user-controlled simple string tags system is added to the > Compute API, a "tag" would be just that, a simple string that may be > attached or detached from some object (in this case, a server object). > > How does this solve all the issues highlighted above? In order, it > solves the issues like so: > > 1. There's no need to have any "server group" object any more. Servers > have a set of tags (key/value pairs in v2/v3 API) that may be used to > identify a type of server. The activity of launching an instance would > now have options for the user to indicate their affinity preference, > which removes the cognitive dissonance that happens due to the user > needing to know what a server group is (a policy, not a group). Would the user's affinity preference stay with the instance for consideration in future operations post-boot (either now or in a future extension of this functionality)? > 2. Since there is no more need to maintain a separate server group > object, if a user launched 3 instances and then wanted to make sure that > 3 new instances don't end up on the same hosts, all the user needs to do > is tag the existing instances with a tag, and issue a call to: > > nova boot --not-near-tag $TAG ... > > and the affinity policy is applied properly. The fact that membership can't be changed, at least in the initial implementation, is explicitly called out in the design wiki for the server group api [1]. My understanding is that this was not because implementing an add/remove that works the way you suggest would have been particularly problematic but because user expectations when the group membership is modified are not just that the new instances booted into the group subsequently are placed with affinity/anti-affinity but that the existing instances that were added to the group are also evaluated and moved as necessary to ensure *all* members of the group meet the policy. So in the example this would mean ensuring that all 6 VMs have anti-affinity, not just the latest 3 that are being booted do (or perhaps I am misreading what you are proposing?). Similarly there is an expectation that it's possible to look at a group and easily determine whether it was placed with a policy, and if so what that policy was (not saying that could not be implemented on top of your proposal, just recording for completeness). Whether solutions to meet these expectations belongs in Nova or somewhere else is probably another matter but when dealing with users who use this functionality and they talk about modifying group membership *this* is what they expect. On the other hand this proposal does seem to offer more flexibility for some more complex use cases, for example where users want to place pairs of instances in their own instance groups with affinity, but have them placed with anti-affinity for other pairs. Perhaps I am missing something in the server groups design (or proposed extensions of it) on this point though. I think everyone agrees that the server groups API as it stands is not the final solution here, but I think it's important to refer back to the previous design summit discussions [2][3] on this functionality and ensure any replacement caters not just to reimplementing the current state of server groups but also ensuring that it's easily extended to cover future needs (particularly those already discussed/considered in framing the current functionality). Thanks, Steve [1] https://wiki.openstack.org/wiki/GroupApiExtension [2] https://etherpad.openstack.org/p/group-scheduling [3] https://etherpad.openstack.org/p/NovaIcehouse-Instance-Group-API _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
