Open Stack

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).

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.

2014-12-22 11:29 GMT+08:00 Joe Cropper <cropper.joe at gmail.com>:

> 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.kong at gmail.com> wrote:
>
> > 2014-12-22 9:21 GMT+08:00 Alex Xu <soulxu at gmail.com>:
> >>
> >>
> >> 2014-12-22 9:01 GMT+08:00 Lingxian Kong <anlin.kong at 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20141222/e0523669/attachment.html>