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).
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 availability" , replacing unavailable state servers and
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-
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).
https:/ /codereview. appspot. com/90160044/