Hi Jay, I'm going to disagree with you on this one, because:
i) This is a feature that was discussed in at least one if not two Design Summits and went through a long review period, it wasn't one of those changes that merged in 24 hours before people could take a good look at it. Whatever you feel about the implementation, it is now in the API and we should assume that people have started coding against it. I don't think it gives any credibility to Openstack as a platform if we yank features back out just after they've landed. ii) Sever Group - It's a way of defining a group of servers, and the initial thing (only thing right now) you can define for such a group is the affinity or anti-affinity for scheduling. Maybe in time we'll add other group properties or operations - like "delete all the servers in a group" (I know some QA folks that would love to have that feature). I don't see why it shouldn't be possible to have a server group that doesn't have a scheduling policy associated to it. I don't see any Cognitive dissonance here - I think your just assuming that the only reason for being able to group servers is for scheduling. iii) If the issue is that you can't add or remove servers from a group, then why don't we add those operations to the API (you could add a server to a group providing doing so doesn't break any policy that might be associated with the group). Seems like a useful addition to me. iv) Since the user created the group, and chose a name for it that is presumably meaningful, then I don't understand why you think "--group XXX" isn't going to be meaningful to that same user ? So I think there are a bunch of API operations missing, but I don't see any advantage in throwing away what's now in place and replacing it with a tag mechanism that basically says "everything with this tag is in a sort of group". Cheers, Phil PS: Congrats on the TC election > -----Original Message----- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: 25 April 2014 22:16 > To: OpenStack Development Mailing List > Subject: [openstack-dev] [nova] Proposal: remove the server groups feature > > Hi Stackers, > > When recently digging in to the new server group v3 API extension > introduced in Icehouse, I was struck with a bit of cognitive dissonance that I > can't seem to shake. While I understand and support the idea behind the > feature (affinity and anti-affinity scheduling hints), I can't help but feel > the > implementation is half-baked and results in a very awkward user experience. > > The use case here is very simple: > > Alice wants to launch an instance and make sure that the instance does not > land on a compute host that contains other instances of that type. > > The current user experience is that the user creates a "server group" > like so: > > nova server-group-create $GROUP_NAME --policy=anti-affinity > > and then, when the user wishes to launch an instance and make sure it > doesn't land on a host with another of that instance type, the user does the > following: > > nova boot --group $GROUP_UUID ... > > There are myriad problems with the above user experience and > implementation. Let me explain them. > > 1. The user isn't creating a "server group" when they issue a nova server- > group-create call. They are creating a policy and calling it a group. > Cognitive > dissonance results from this mismatch. > > 2. There's no way to add an existing server to this "group". What this means > is that the user needs to effectively have pre-considered their environment > and policy before ever launching a VM. To realize why this is a problem, > consider the following: > > - User creates three VMs that consume high I/O utilization > - User then wants to launch three more VMs of the same kind and make > sure they don't end up on the same hosts as the others > > No can do, since the first three VMs weren't started using a --group > scheduler hint. > > 3. There's no way to remove members from the group > > 4. There's no way to manually add members to the server group > > 5. The act of telling the scheduler to place instances near or away from some > other instances has been hidden behind the server group API, which means > that users doing a nova help boot will see a --group option that doesn't make > much sense, as it doesn't describe the scheduling policy activity. > > 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. > > 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). > > 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. > > 3. Removal of members of the "server group" is no longer an issue. > Simply untag a server to remove it from the set of servers you wish to use in > applying some affinity policy > > 4. Likewise, since there's no server group object, in order to relate an > existing > server to another is to simply place a tag on the server. > > 5. The act of applying affinity policies is now directly related to the act of > launching instances, which is where it should be. > > I'll type up a real blueprint spec for this, but wanted to throw the idea out > there, since it's something that struck me recently when I tried to explain > the > new server groups feature. > > Thoughts and feedback welcome, > -jay > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
