The "bootstrap node" needs high availability

[Clint Byrum]

Currently the bootstrap step spawns one machine with zookeeper and the provisioning agent on it. These should be spawned on more than one machine and linked together so that they are not a single point of failure.

[Benjamin Saller (bcsaller)]

I might go so far as to suggest that we model this as an LXC container on some percentage of all deployed nodes in the environment running along side the machine agent its its managed service units.

The EC2 providers notions around `machine 0` go away and this becomes a distributed concern. It moves us in the intended direction of using ensembles service model to deploy itself as well.

[Chris Christensen (christianchristensen)]

(Putting some notes here from an IRC discussion...)
20:26:14 < chrischris> I'm actually curious if an additional zookeeper relation to the bootstrap node could be made as another charm config
23:31:25 < SpamapS> chrischris: negronjl has monkied with the zookeeper charm to allow it to be deployed as a 3-node quorum for the bootstrap machine
23:31:48 < SpamapS> chrischris: the HA problem is addressed in juju-core (rewrite in go with mongodb instead of zookeeper)

[Kapil Thangavelu (hazmat)]

this isn't the case yet re juju-core, but it is an issue being looked at.

[Данило Шеган (danilo)]

This is being addressed with https://blueprints.launchpad.net/juju-core/+spec/s-cloud-juju-ha for juju-core.

[Dustin Kirkland  (kirkland)]

Hi Danilo,

What's the reasoning behind lowering this from High to Wishlist? From my perspective, this is the most critical bug in all of juju-core. Perhaps it can be called a "High", since there's a workaround (juju export).

Thanks!
Dustin

[John A Meinel (jameinel)]

High generally denotes that it is actively on our todo map for this cycle. It turns out that someone is working on this (Gustavo is spiking on it). So I'm willing to put it back to High.