High Availability command line interface - future plans.

Nate Finch nate.finch at canonical.com
Wed Nov 6 20:02:38 UTC 2013


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.

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.

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?


On Wed, Nov 6, 2013 at 2:56 PM, Nate Finch <nate.finch at canonical.com> wrote:

> 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.
>
> More inline:
>
> On Wed, Nov 6, 2013 at 1:49 PM, roger peppe <rogpeppe at gmail.com> wrote:
>
>> The current plan is to have a single "juju ensure-ha-state" juju
>> command. This would create new state server machines if there are less
>> than the required number (currently 3).
>>
>> Taking that as given, I'm wondering what we should do
>> in the future, when users require more than a single
>> big On switch for HA.
>>
>> How does the user:
>>
>> a) know about the HA machines so the costs of HA are not hidden, and that
>> the implications of particular machine failures are clear?
>>
>
> - As above, documentation about what it means when you see servers in juju
> status labelled as "Juju State Server" (or whatever).
>
> - Have actual feedback from commands:
>
> $ juju bootstrap --high-availability
> Machines 0, 1, and 2 provisioned as juju server nodes.
> Juju successfully bootstrapped environment Foo in high availability mode.
>
> or
>
> $ juju bootstrap
> Machine 0 provisioned as juju server node.
> Juju successfully bootstrapped environment Foo.
>
> $ juju ensure-ha -n 7
> Enabling high availability mode with 7 juju servers.
> Machines 1, 2, 3, 4, 5, and 6 provisioned as additional Juju server nodes.
>
> $ juju ensure-ha -n 5
> Reducing number of Juju server nodes to 5.
> Machines 2 and 6 destroyed.
>
> b) fix the system when a machine dies?
>>
>
> $ juju destroy-machine 5
> Destroyed machine/5.
> Automatically replacing destroyed Juju server node.
> Machine/8 created as new Juju server node.
>
>
>> c) scale up the system to x thousand nodes
>
>
> 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
>
>
>> d) scale down the system?
>>
>
>  $ juju disable-ha -y
> Destroyed machine/1 and machine/2.
> The Juju server node for environment Foo is machine/0.
> High availability mode disabled for Juju environment Foo.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20131106/17491635/attachment-0001.html>


More information about the Juju mailing list