Open Stack

I tend to agree that that shouldn't be placed in nova. As it happens I'm working on very same thing (hello Russell :)). My current candidate is heat. Convergence will be in my opinion great place to do it (https://review.openstack.org/#/c/95907/). It's still in state of planning, but we'll talk about that more in Paris. I even have working demo of automatic evacuation :) (come to intel booth in Paris if you'd like to see it).

Thing is, nova currently isn't ready for that. For example:  https://bugs.launchpad.net/nova/+bug/1379292
We are working on bp to enable nova to check actual host health, not only nova services health (bp coming soon, but in short its enabling zookeeper servicegroup api to monitor for example libvirt, or something else which, if down, means vms are dead).
That won't replace actual fencing, but that's something, and even if we would like to have fencing in nova, that's an requirement.

Maybe it's worth a design session? I've seen this or similar idea in several places already, and demand is strong for that.

Regards,
Michał

> -----Original Message-----
> From: Russell Bryant [mailto:rbryant at redhat.com]
> Sent: Tuesday, October 14, 2014 8:55 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] Automatic evacuate
> 
> On 10/14/2014 01:01 PM, Jay Pipes wrote:
> >> 2) Looking forward, there is a lot of demand for doing this on a per
> >> instance basis.  We should decide on a best practice for allowing end
> >> users to indicate whether they would like their VMs automatically
> >> rescued by the infrastructure, or just left down in the case of a
> >> failure.  It could be as simple as a special tag set on an instance [2].
> >
> > Please note that server instance tagging (thanks for the shout-out,
> > BTW) is intended for only user-defined tags, not system-defined
> > metadata which is what this sounds like...
> 
> I was envisioning the tag being set by the end user to say "please keep my
> VM running until I say otherwise", or something like "auto-recover"
> for short.
> 
> So, it's specified by the end user, but potentially acted upon by the system
> (as you say below).
> 
> > Of course, one might implement some external polling/monitoring system
> > using server instance tags, which might do a nova list --tag $TAG
> > --host $FAILING_HOST, and initiate a migrate for each returned server
> instance...
> 
> Yeah, that's what I was thinking.  Whatever system you use to react to a
> failing host could use the tag as part of the criteria to figure out which
> instances to evacuate and which to leave as dead.
> 
> --
> Russell Bryant
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--------------------------------------------------------------------

Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i moze zawierac informacje poufne. W razie przypadkowego otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; jakiekolwiek
przegladanie lub rozpowszechnianie jest zabronione.
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by
others is strictly prohibited.