> -----Original Message----- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: 25 April 2014 23:29 > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [nova] Proposal: remove the server groups > feature > > On Fri, 2014-04-25 at 22:00 +0000, Day, Phil wrote: > > Hi Jay, > > > > I'm going to disagree with you on this one, because: > > No worries, Phil, I expected some dissention and I completely appreciate > your feedback and perspective :) > Always happy to meet your expectations ;-)
Seem that where we mainly disagree is on the usability of the current Server Group API - and maybe we just need a wider range of views to see where the majority feeling is on that. The folks we've got who have been looking for affinity/anti-affinity scheduling (we've been holding off from the previous filters because they include DB lookups) don't seem to find the Server Groups schematic confusing - you know you want to do something with a group of servers so you create a group, define the properties for that group, and add servers to it as you create them. I agree there are a number of things needed to round this out (such as add/remove server, and some form of quota on the maximum size of a group), but I just don't see the basic approach as broken in the way that you do - and I am worried that we end up spinning on much needed functionality if we start to rework it now. The tagging approach (if I understand it correctly) seems like it would start to introduce system schematics to values that are currently just user defined free text - which I think might lead to more confusion / name-space clashes around which tags are now in effect reserved names and which are still user defined. I think I prefer the clearer separation. Phil > > 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. > > Completely understood. That still doesn't mean we can't propose to get rid > of it early instead of letting it sit around when an alternate implementation > would be better for the user of OpenStack. > > > Whatever you feel about the implementation, it is now in the API and we > should assume that people have started coding against it. > > Sure, maybe. AFAIK, it's only in the v2 API, though, not in the v3 API > (sorry, I > made a mistake about that in my original email). Is there a reason it wasn't > added to the v3 API? > > > I don't think it gives any credibility to Openstack as a platform if we > > yank > features back out just after they've landed. > > Perhaps not, though I think we have less credibility if we don't recognize > when a feature isn't implemented with users in mind and leave it in the code > base to the detriment and confusion of users. We absolutely must, IMO, as a > community, be able to say "this isn't right" > and have a path for changing or removing something. > > If that path is deprecation vs outright removal, so be it, I'd be cool with > that. > I'd just like to nip this anti-feature in the bud early so that it doesn't > become > the next "feature" like file-injection to persist in Nova well after its time > has > come and passed. > > > 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. > > We already had ways of defining groups of servers. This new "feature" > doesn't actually define a group of servers. It defines a policy, which is not > particularly useful, as it's something that is better specified at the time of > launching. > > > 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). > > We already have the ability to define a group of servers using key=value tags. > Deleting all servers in a group is a three-line bash script that loops over > the > results of a nova list command and calls nova delete. > Trust me, I've done group deletes in this way many times. > > > 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 think the grouping of servers should have *anything* to do with > scheduling :) That's the point of my proposal. Servers can and should be > grouped using simple tags or key=value pair tags. > > The grouping of servers together doesn't have anything of substance to do > with scheduling policies. > > > 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. > > Again, I don't think scheduling and grouping of servers has anything to do > with each other, thus my proposal to remove the relationship between > groups of servers and scheduling policies, which is what the existing server > group API and implementation does. > > > 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). > > We already have this ability today, thus my proposal to get rid of server > groups. > > > Seems like a useful addition to me. > > It's an addition that isn't needed, as we already have this today. > > > 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 ? > > See point above about removing the unnecessary relationship between > grouping of servers and scheduling policies. > > > 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". > > We already have the tag group mechanism in place, that's kind of what I've > been saying... > > > PS: Congrats on the TC election > > Cheers, appreciated. Looking forward to healthy debates and buying you a > few beers at the summit :) > > best, > -jay > > > > > > -----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 > > > > _______________________________________________ > 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