<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 26, 2014 at 5:15 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Stackers,<br>
<br>
When recently digging in to the new server group v3 API extension<br>
introduced in Icehouse, I was struck with a bit of cognitive dissonance<br>
that I can't seem to shake. While I understand and support the idea<br>
behind the feature (affinity and anti-affinity scheduling hints), I<br>
can't help but feel the implementation is half-baked and results in a<br>
very awkward user experience.<br>
<br>
The use case here is very simple:<br>
<br>
Alice wants to launch an instance and make sure that the instance does<br>
not land on a compute host that contains other instances of that type.<br>
<br>
The current user experience is that the user creates a "server group"<br>
like so:<br>
<br>
nova server-group-create $GROUP_NAME --policy=anti-affinity<br>
<br>
and then, when the user wishes to launch an instance and make sure it<br>
doesn't land on a host with another of that instance type, the user does<br>
the following:<br>
<br>
nova boot --group $GROUP_UUID ...<br>
<br>
There are myriad problems with the above user experience and<br>
implementation. Let me explain them.<br>
<br>
1. The user isn't creating a "server group" when they issue a nova<br>
server-group-create call. They are creating a policy and calling it a<br>
group. Cognitive dissonance results from this mismatch.<br>
<br>
2. There's no way to add an existing server to this "group". What this<br>
means is that the user needs to effectively have pre-considered their<br>
environment and policy before ever launching a VM. To realize why this<br>
is a problem, consider the following:<br>
<br>
- User creates three VMs that consume high I/O utilization<br>
- User then wants to launch three more VMs of the same kind and make<br>
sure they don't end up on the same hosts as the others<br>
<br>
No can do, since the first three VMs weren't started using a --group<br>
scheduler hint.<br>
<br>
3. There's no way to remove members from the group<br>
<br>
4. There's no way to manually add members to the server group<br>
<br>
5. The act of telling the scheduler to place instances near or away from<br>
some other instances has been hidden behind the server group API, which<br>
means that users doing a nova help boot will see a --group option that<br>
doesn't make much sense, as it doesn't describe the scheduling policy<br>
activity.<br>
<br>
Proposal<br>
--------<br>
<br>
I propose to scrap the server groups API entirely and replace it with a<br>
simpler way to accomplish the same basic thing.<br>
<br>
Create two new options to nova boot:<br>
<br>
--near-tag <TAG><br>
and<br>
--not-near-tag <TAG><br>
<br></blockquote><div><br>Hi jay,<br><br></div><div>I have a little question.<br></div><div>Whether it will support multiple tags for the server?<br></div><div>Maybe we hope a server to near some servers and not near another servers currently.<br>
<br><p><span style="font-family:"Arial","sans-serif"" lang="EN-US">Best regards to you.</span></p>
<span style="font-family:"Arial","sans-serif"" lang="EN-US">Ricky</span><br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The first would tell the scheduler to place the new VM near other VMs<br>
having a particular "tag". The latter would tell the scheduler to place<br>
the new VM *not* near other VMs with a particular tag.<br>
<br>
What is a "tag"? Well, currently, since the Compute API doesn't have a<br>
concept of a single string tag, the tag could be a key=value pair that<br>
would be matched against the server extra properties.<br>
<br>
Once a real user-controlled simple string tags system is added to the<br>
Compute API, a "tag" would be just that, a simple string that may be<br>
attached or detached from some object (in this case, a server object).<br>
<br>
How does this solve all the issues highlighted above? In order, it<br>
solves the issues like so:<br>
<br>
1. There's no need to have any "server group" object any more. Servers<br>
have a set of tags (key/value pairs in v2/v3 API) that may be used to<br>
identify a type of server. The activity of launching an instance would<br>
now have options for the user to indicate their affinity preference,<br>
which removes the cognitive dissonance that happens due to the user<br>
needing to know what a server group is (a policy, not a group).<br>
<br>
2. Since there is no more need to maintain a separate server group<br>
object, if a user launched 3 instances and then wanted to make sure that<br>
3 new instances don't end up on the same hosts, all the user needs to do<br>
is tag the existing instances with a tag, and issue a call to:<br>
<br>
nova boot --not-near-tag $TAG ...<br>
<br>
and the affinity policy is applied properly.<br>
<br>
3. Removal of members of the "server group" is no longer an issue.<br>
Simply untag a server to remove it from the set of servers you wish to<br>
use in applying some affinity policy<br>
<br>
4. Likewise, since there's no server group object, in order to relate an<br>
existing server to another is to simply place a tag on the server.<br>
<br>
5. The act of applying affinity policies is now directly related to the<br>
act of launching instances, which is where it should be.<br>
<br>
I'll type up a real blueprint spec for this, but wanted to throw the<br>
idea out there, since it's something that struck me recently when I<br>
tried to explain the new server groups feature.<br>
<br>
Thoughts and feedback welcome,<br>
-jay<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>