<div dir="ltr"><div><div><div><div>I think server group is an important feature especially when working with heat auto scaling group, there is already some discussion for this <a href="http://markmail.org/message/jl5wlx3nr3g53ko5">http://markmail.org/message/jl5wlx3nr3g53ko5</a><br>
<br></div>The current server group feature does support add/delete a VM instance to/from the server group but seems not able to manage existing VM instances, but this can be enhanced.<br><br></div><div>The server group feature need two steps to create the VM instance:<br>
</div><div>1) Create a server group with policy<br></div><div>2) Create VMs for the server group<br><br></div><div>What Jay Pipes proposed is using resource tags directly:<br></div><div>1) Create VMs with a resource tag to specify the policy.<br>
<br></div><div>I think that those two directions are very similar, but what Jay Pipes proposed does not specify the resource group and seems the resource group was implicitly specified in resource tag. <br><br>Just some of my understanding. Thanks!<br>
<br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-27 1:25 GMT+08:00 Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Apr 25, 2014, at 2:25 PM, Chris Behrens <<a href="mailto:cbehrens@codestud.com">cbehrens@codestud.com</a>> wrote:<br>
<br>
><br>
> On Apr 25, 2014, at 2:15 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
><br>
>> 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>
> I agree with all you said about this.<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>
>> 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>
> You can actually already achieve this behavior… although with a little more work. There’s the Affinty filter which allows you to specify a same_host/different_host scheduler hint where you explicitly specify the instance uuids you want… (the extra work is having to know the instance uuids).<br>
<br>
</div></div>It was my understanding from previous discussions that having the concept of a group was necessary for future schediuling decisions, especially involving live migration. The uuids you need to be far from at launch time won’t necessarily be the ones you need to be far from when a migration is performed. Server groups handle this case, although Jay’s proposal of near/far from tag would also solve this as long as the near-to/far-from data was saved in the instance record. My only concern here is removing an api we just added, so a smoother transition would be preferable.<br>
<br>
Vish<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> But yeah, I think this makes more sense to me.<br>
><br>
> - Chris<br>
><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>
<br>
</div></div><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>
<br></blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div>Thanks,<br><br></div>Jay<br></div>
</div>