Open Stack

> -----Original Message-----
> From: Jay Pipes [mailto:jaypipes at gmail.com]
> Sent: 25 April 2014 23:29
> To: openstack-dev at 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:jaypipes at 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 at lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev