Open Stack

On 2016-08-01 19:26:07 +0200 (+0200), Frank Kloeker wrote:
> broken DevStack installation - that's the point. With LXD
> container you can take snapshot, run unstack or clean script,
> fetch new code and stack again. If it failed you can restore the
> snapshot and try new installation on another day. Without snapshot
> you can start new container with new code and shutdown the old
> one. So I like the idea with haproxy in front but wouldn't change
> any DNS entries because it takes time for end-users.

Sure, but those are also things we can do (and already do) with
virtual machines in many places, while we're not currently
maintaining any container-based services at all. I'm just saying
that "use containers" isn't a solution per se, and we should first
focus on the patterns we'll use to bootstrap DevStack, check that it
works and switch rather than jumping to whether this
needs to be containerized to make that possible.

> If you have enough resources then we can work with 3 VMs: 2
> DevStack installation with translation check-site and one with
> haproxy hosting the public FQDN and a kind of trigger to refresh
> the installation on the DevStack VM _if_ the other VM is up. If
> the other DevStack service is down, the trigger should try an
> unstack/clean/stack after one day and switch over if the service
> is up. This could be done with lb-update
> (https://www.haproxy.com/doc/aloha/7.0/haproxy/lbupdate.html) or
> haproxy API. The process should have a small monitoring about the
> status.

I'm hesitant to rely on unstack/clean/stack working consistently
over time, though maybe others have seen them behave more reliably
than I think they do. I had assumed we'd replace with fresh servers
each time and bootstrap DevStack from scratch, though perhaps that's
overkill?
-- 
Jeremy Stanley