Open Stack

On 2013-04-24 07:02, Russell Bryant wrote:
> On 04/24/2013 09:51 AM, Leen Besselink wrote:
>> On Wed, Apr 24, 2013 at 09:35:19AM -0400, Russell Bryant wrote:
>>> On 04/23/2013 08:20 PM, Robert Collins wrote:
>>>> +1 on using Heat to orchestrate the response to a node failure.
>>> 
>>> Yeah, it's quite clever, I like it.  It's as if you TripleO folks 
>>> are on
>>> to something here.  ;-)
>>> 
>> 
>> I thought the same thing, until I realized that maybe not everyone 
>> wants to setup
>> OpenStack on OpenStack. But might still want VM HA.
> 
> If folks want to diverge from "the OpenStack way", that's perfectly
> fine.  In that case we just need to make sure all of the primitives 
> are
> there for someone to implement their own solution.
> 
> As far as I know, the compute API already exposes the primitives
> necessary here.  If you detect a compute node failure using your 
> Thing,
> you can use live-migrate or evacuate, depending on whether the compute
> node is on its way to dying, or is already dead.

Sometimes the definite article gives our statements more weight than 
they can bear.

I just want to put it out there that "OpenStack on OpenStack" isn't 
necessarily "the OpenStack way". Nor is Heat "the TripleO way". We are 
pushing for a tool chain which has an opinion, not an edict.

That said, Heat's job is to orchestrate multi-node operations involving 
API calls. This seems like a slam dunk. So if you wanted to implement 
this feature, it would make most sense to approach it with two tasks:

1) make sure APIs are available to do it.
2) Put the orchestration piece of said calls in Heat.

Heat has a plugin system, so you should be able to do this mostly by 
just implementing a resource plugin which extends the instance resource. 
Also take a look at the OS::Heat::HARestarter resource for ideas.