cmd/juju/ensureavailability: default to 3 servers

cmd/juju/ensureavailability: default to 3 servers

I filed bug #1311083 because we currently have a default of '-1' and we
immediately fail when running the command. I don't think this is very
good UI for a user. I think we can make an opinionated statement that
n=3 is going to be the best for someone who wants to run this command.
And that is what this patch does.

https://code.launchpad.net/~jameinel/juju-core/ensure-availability-default-3-1311083/+merge/216706

(do not edit description out of merge proposal)

[jameinel, 2014-04-22 12:32:29]

Please take a look.

[axw, 2014-04-22 12:42:23]

On 2014/04/22 12:32:29, jameinel wrote:
> Please take a look.

I originally just defaulted it to 1, but rog asked me to take out the default so
that we can, in the future, change the command to maintain the current
availability. That would enable a simple cron job to periodically "juju
ensure-availability", replacing unavailable state servers and reinstating
available ones.

[jameinel, 2014-04-22 14:11:08]

On 2014/04/22 12:42:23, axw wrote:
> On 2014/04/22 12:32:29, jameinel wrote:
> > Please take a look.
> 
> I originally just defaulted it to 1, but rog asked me to take out the default
so
> that we can, in the future, change the command to maintain the current
> availability. That would enable a simple cron job to periodically "juju
> ensure-availability", replacing unavailable state servers and reinstating
> available ones.

ensure-availability 1 can't ever do anything.

Because if 1 machine is dead, there is nobody to contact to set up availability.
And if you pass 1 to a system that has 3, you get a message about "you cannot
reduce the number", because we would be trying to decrease from 3 to 1.

There is room to say that "ensure-availability" with nothing specified is
actually -1, which means "3 if you are currently running with only 1, and N if
you are currently running with N".

I would be happy to make that change, so that we allow -1 or 0 to be passed up,
and then interpret it according to the above rules.

But *quite honestly* I don't expect anyone to ever run with anything but 1 or 3,
so making it overly flexible doesn't actually gain us much. (It is possible that
in a year or more we'll have found ways to scale beyond 3 productively, I don't
think we're anywhere close to that yet).

[rog, 2014-04-22 14:18:32]

On 2014/04/22 14:11:08, jameinel wrote:
> On 2014/04/22 12:42:23, axw wrote:
> > On 2014/04/22 12:32:29, jameinel wrote:
> > > Please take a look.
> > 
> > I originally just defaulted it to 1, but rog asked me to take out the
default
> so
> > that we can, in the future, change the command to maintain the current
> > availability. That would enable a simple cron job to periodically "juju
> > ensure-availability", replacing unavailable state servers and reinstating
> > available ones.
> 
> ensure-availability 1 can't ever do anything.
> 
> Because if 1 machine is dead, there is nobody to contact to set up
availability.
> And if you pass 1 to a system that has 3, you get a message about "you cannot
> reduce the number", because we would be trying to decrease from 3 to 1.

That should be fixed eventually - we should allow people to reduce their
state server count.

> There is room to say that "ensure-availability" with nothing specified is
> actually -1, which means "3 if you are currently running with only 1, and N if
> you are currently running with N".

That was the plan.

> I would be happy to make that change, so that we allow -1 or 0 to be passed
up,
> and then interpret it according to the above rules.

SGTM

[wallyworld, 2014-04-23 04:05:14]

LGTM

https://codereview.appspot.com/90160044/diff/1/cmd/juju/ensureavailability.go
File cmd/juju/ensureavailability.go (right):

https://codereview.appspot.com/90160044/diff/1/cmd/juju/ensureavailability.go...
cmd/juju/ensureavailability.go:36: juju ensure-availability
nitpick - add another example showing use of n?, eg
juju ensure-availability -n 5
Ensure that 5 state servers ....

[jameinel, 2014-04-23 06:55:47]

Please take a look.

[axw, 2014-04-23 07:12:14]

On 2014/04/23 06:55:47, jameinel wrote:
> Please take a look.

LGTM