<div dir="ltr">Joe, thanks, that's useful feature. But still not sure it's good for this case. Thinking of user's server-group will be deleted by administrator and new server-group created for user by administrator, that sounds confused for user. I'm thinking of the HA case, if there is host failed, the infrastructure can evacuate instance out of failed host automatically, and user shouldn't be affected by that(user still will know his instance is down, and the instance get back later. At least we should reduce the affect).<div><br></div><div>I think the key is whether we think evacuate instance out of failed host that in affinity group is violation or not. The host already failed, we can ignore the failed host which in server group when we evacuate first instance to another host. After first instance evacuated, there is new alive host in the server group, then other instances will be evacuated to that new alive host to comply affinity policy.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-22 11:29 GMT+08:00 Joe Cropper <span dir="ltr"><<a href="mailto:cropper.joe@gmail.com" target="_blank">cropper.joe@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is another great example of a use case in which these blueprints [1, 2] would be handy.  They didn’t make the clip line for Kilo, but we’ll try again for L.  I personally don’t think the scheduler should have “special case” rules about when/when not to apply affinity policies, as that could be confusing for administrators.  It would be simple to just remove it from the group, thereby allowing the administrator to rebuild the VM anywhere s/he wants… and then re-add the VM to the group once the environment is operational once again.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/136487/" target="_blank">https://review.openstack.org/#/c/136487/</a><br>
[2] <a href="https://review.openstack.org/#/c/139272/" target="_blank">https://review.openstack.org/#/c/139272/</a><br>
<span class="HOEnZb"><font color="#888888"><br>
- Joe<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Dec 21, 2014, at 8:36 PM, Lingxian Kong <<a href="mailto:anlin.kong@gmail.com">anlin.kong@gmail.com</a>> wrote:<br>
<br>
> 2014-12-22 9:21 GMT+08:00 Alex Xu <<a href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>>:<br>
>><br>
>><br>
>> 2014-12-22 9:01 GMT+08:00 Lingxian Kong <<a href="mailto:anlin.kong@gmail.com">anlin.kong@gmail.com</a>>:<br>
>>><br>
><br>
>>><br>
>>> but what if the compute node is back to normal? There will be<br>
>>> instances in the same server group with affinity policy, but located<br>
>>> in different hosts.<br>
>>><br>
>><br>
>> If operator decide to evacuate the instance from the failed host, we should<br>
>> fence the failed host first.<br>
><br>
> Yes, actually. I mean the recommandation or prerequisite should be<br>
> emphasized somewhere, e.g. the Operation Guide, otherwise it'll make<br>
> things more confused. But the issue you are working around is indeed a<br>
> problem we should solve.<br>
><br>
> --<br>
> Regards!<br>
> -----------------------------------<br>
> Lingxian Kong<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>
<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>
</div></div></blockquote></div><br></div>