Open Stack

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 :)

> 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