Open Stack

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