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.
[1] https://review.openstack.org/#/c/136487/ [2] https://review.openstack.org/#/c/139272/ - Joe On Dec 21, 2014, at 8:36 PM, Lingxian Kong <anlin.k...@gmail.com> wrote: > 2014-12-22 9:21 GMT+08:00 Alex Xu <sou...@gmail.com>: >> >> >> 2014-12-22 9:01 GMT+08:00 Lingxian Kong <anlin.k...@gmail.com>: >>> > >>> >>> but what if the compute node is back to normal? There will be >>> instances in the same server group with affinity policy, but located >>> in different hosts. >>> >> >> If operator decide to evacuate the instance from the failed host, we should >> fence the failed host first. > > Yes, actually. I mean the recommandation or prerequisite should be > emphasized somewhere, e.g. the Operation Guide, otherwise it'll make > things more confused. But the issue you are working around is indeed a > problem we should solve. > > -- > Regards! > ----------------------------------- > Lingxian Kong > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
