<div dir="ltr">Oops, missed the end of a thought there. If we get to the point of needing more than 12 server nodes (not unfathomable), then we have to start doing some more work for our "hyperscale" customers, which will probably involve much more customization and require much more knowledge of the system.<div>
<br></div><div>I think one of the points of making HA simple is that we don't want people to have to learn how Juju works before they can deploy their own stuff in a robust manner. Keep the barrier of entry as low as possible. We can give general guidelines about how many Juju servers you need for N unit agents, and then people will know what to set N to, when they do juju ensure-ha -n.</div>
<div><br></div><div>I think most people will be happy knowing there are N servers out there, and if one goes down, another will take its place. They don't want to know about this job and that job. Just make it work and let me get on with my life. That's kind of the whole point of Juju, right?</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Nov 6, 2013 at 2:56 PM, Nate Finch <span dir="ltr"><<a href="mailto:nate.finch@canonical.com" target="_blank">nate.finch@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The answer to "how does the user know how to X?" is the same as it always has been. Documentation. Now, that's not to say that we still don't need to do some work to make it intuitive... but I think that for something that is complicated like HA, leaning on documentation a little more is ok.<div>
<br></div><div>More inline:</div><div class="gmail_extra"><br><div class="gmail_quote"><div class="im">On Wed, Nov 6, 2013 at 1:49 PM, roger peppe <span dir="ltr"><<a href="mailto:rogpeppe@gmail.com" target="_blank">rogpeppe@gmail.com</a>></span> wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The current plan is to have a single "juju ensure-ha-state" juju<br>
command. This would create new state server machines if there are less<br>
than the required number (currently 3).<br>
<br>
Taking that as given, I'm wondering what we should do<br>
in the future, when users require more than a single<br>
big On switch for HA.<br>
<br>
How does the user:<br>
<br>
a) know about the HA machines so the costs of HA are not hidden, and that<br>
the implications of particular machine failures are clear?<br></blockquote><div><br></div></div><div>- As above, documentation about what it means when you see servers in juju status labelled as "Juju State Server" (or whatever).</div>
<div><br></div><div>- Have actual feedback from commands:</div><div><br></div><div>$ juju bootstrap --high-availability</div><div>Machines 0, 1, and 2 provisioned as juju server nodes.<br></div><div><div>Juju successfully bootstrapped environment Foo in high availability mode.</div>
</div><div><br></div><div>or</div><div><br></div><div>$ juju bootstrap</div><div>Machine 0 provisioned as juju server node.</div><div>Juju successfully bootstrapped environment Foo.</div><div><br></div><div>$ juju ensure-ha -n 7</div>
<div>Enabling high availability mode with 7 juju servers.</div><div>Machines 1, 2, 3, 4, 5, and 6 provisioned as additional Juju server nodes.</div><div><br></div><div>$ juju ensure-ha -n 5</div><div>Reducing number of Juju server nodes to 5.</div>
<div>Machines 2 and 6 destroyed.</div><div class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
b) fix the system when a machine dies?<br>
</blockquote><div><br></div></div><div>$ juju destroy-machine 5</div><div>Destroyed machine/5.</div><div>Automatically replacing destroyed Juju server node.</div><div>Machine/8 created as new Juju server node.</div><div class="im">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
c) scale up the system to x thousand nodes</blockquote><div><br></div></div><div>Hopefully 12 machines is plenty of Juju servers for 5000 nodes. We will need to revisit this if it's not, but it seems like it should be plenty. As above, I think a simple -n is fine for both raising and lowering the number of state servers. If we get to the point of needing more than </div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
d) scale down the system?<br></blockquote><div><br></div></div><div> $ juju disable-ha -y</div><div>Destroyed machine/1 and machine/2.</div><div>The Juju server node for environment Foo is machine/0.</div><div>High availability mode disabled for Juju environment Foo. </div>
<div><br></div></div></div></div>
</blockquote></div><br></div>