Re: High Availability command line interface - future plans.

2013-11-07 Thread roger peppe
I've just realised that all the traffic for this thread was actually in juju-dev, so I'll revert to there. Another cross post then, my apologies. On 7 November 2013 09:21, roger peppe wrote: > On 6 November 2013 20:07, Kapil Thangavelu > wrote: >> instead of adding more complexity and concepts,

Re: High Availability command line interface - future plans.

2013-11-07 Thread roger peppe
On 6 November 2013 20:07, Kapil Thangavelu wrote: > instead of adding more complexity and concepts, it would be ideal if we > could reuse the primitives we already have. ie juju environments have three > user exposed services, that users can add-unit / remove-unit etc. they have > a juju prefix a

Re: High Availability command line interface - future plans.

2013-11-06 Thread David Cheney
+1 (million), this solution keeps coming up, and I still feel it is the right one. On Thu, Nov 7, 2013 at 7:07 AM, Kapil Thangavelu wrote: > > > > On Thu, Nov 7, 2013 at 2:49 AM, roger peppe wrote: >> >> The current plan is to have a single "juju ensure-ha-state" juju >> command. This would crea

Re: High Availability command line interface - future plans.

2013-11-06 Thread Nate Finch
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

Re: High Availability command line interface - future plans.

2013-11-06 Thread Kapil Thangavelu
On Thu, Nov 7, 2013 at 2:49 AM, roger peppe 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 t

Re: High Availability command line interface - future plans.

2013-11-06 Thread Nate Finch
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. Mor

Re: High Availability command line interface - future plans.

2013-11-06 Thread Nick Veitch
just my tuppence... Would it not be clearer to add an additional command to implement your proposal? E.g. "add-manager" and possibly "destroy/remove-manager" This could also support switches for later fine control, and possibly be less open to misinterpretation than overloading the add-machine com