Open Stack

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

Before I had seen your email and I came to similar conclusions. I needed
to learn about Heat first and already found the HARestarter.

You mentioned plugin, I guess that means code. Could it also be implemented
as a template ?

So what I think I now understand is and what my opinion is at this time:

- people not using Heat and baremetal nodes (not specifically TrippleO) will
not get the benefit of the HARestarter.

- we will need an API for fencing and it needs to be plugable so people can
use the implementations that fit their environment (or people should create a
template that calls this choice of implematation ?)

- I assume fencing only applies to baremetal instances

- I think maybe the extra calls to the fencing API be implemented as 'just an other
nestable HEAT template' that only applies to baremetal instances.

Now I have 2 questions:

- if you have TrippleO and the baremetal instance is handled by the under cloud
and the virtual instances running on it are handled by the over cloud. How do
you prevent the over cloud from automatically starting the virtual instances
somewhere else before the baremetal instance has been fenced ?

- if ZooKeeper is used to monitor baremetal instances and OpenStack needs a way
to prevent split-brain situations. I assume baremetal instances have at least 2
network connections, like: management network, storage network or "public" network
like a connection to the Internet or the rest of the Enterprise. Can't you use
atleast 2 ZooKeeper installations ? One for each network.

Here is where I've been writing stuff to get ideas:

https://etherpad.openstack.org/openstack-instance-high-availability