Re: High Availability command line interface - future plans.

In the end I think it comes down to a philosophical difference. I believe in implementing systems from the bottom up out of well understood simple-as-possible components with easily understood properties. I am aware that another approach is to start with a partially implemented primitive that rep

Re: High Availability command line interface - future plans.

On 09/11/13 03:04, roger peppe wrote: > On 8 November 2013 13:51, Gustavo Niemeyer wrote: >> juju add-state-server --api-only-please-thanks > > And if we want to allow a machine that runs the environment-manager > workers but not the api server or mongo server (not actually an unlikely thing > gi

Re: High Availability command line interface - future plans.

It doesn't feel like the difference between juju ensure-ha --prefer-machines 11,37 and juju add-state-server --to 11,37 is worth the amount of reasoning there. I'm clearly in favor of the latter, but I wouldn't argue so much for it. On Fri, Nov 8, 2013 at 2:00 PM, William Reade wrot

Re: High Availability command line interface - future plans.

> On Fri, Nov 8, 2013 at 7:31 PM, Gustavo Niemeyer wrote: > > >> It sounds like we should avoid using a "management" command for >> anything in juju, though. Most things in juju are about management one >> way or the other, so "juju management" becomes very unclear and hard >> to search for. >> >

Fwd: High Availability command line interface - future plans.

Opps, I only responded to William rather than the whole group. -- Forwarded message -- From: Mark Canonical Ramm-Christensen Date: Sat, Nov 9, 2013 at 2:02 AM Subject: Re: High Availability command line interface - future plans. To: William Reade On Sat, Nov 9, 2013 at 12

Fwd: High Availability command line interface - future plans.

Oops, I seem to be hitting reply rather than reply-all tonight! Here's a message I intended to send to everybody, and only sent to Gustavo. On Fri, Nov 8, 2013 at 7:31 PM, Gustavo Niemeyer wrote: > These are *very* good points, Mark. Taking them to heart will > definitely lead into a good direc

Re: High Availability command line interface - future plans.

Scaling jobs independently doesn't really get you much. If you need 7 machines of redundancy for mongo... why would you not just also want the API on all 7 machines? It's 100% upside... now your API is that much more redundant/scaled, and we already know the API and mongo run just fine together o

Re: High Availability command line interface - future plans.

I'm concerned that we're (1) rehashing decisions made during the sprint and (2) deviating from requirements in doing so. In particular, abstracting HA away into "management" manipulations -- as roger notes, pretty much isomorphic to the "jobs" proposal -- doesn't give users HA so much as it gives

Re: High Availability command line interface - future plans.

On Fri, Nov 8, 2013 at 12:04 PM, roger peppe wrote: > On 8 November 2013 13:51, Gustavo Niemeyer wrote: >> juju add-state-server --api-only-please-thanks > > And if we want to allow a machine that runs the environment-manager > workers but not the api server or mongo server (not actually an unlik

Re: High Availability command line interface - future plans.

Reminds me of one of my favorite quotes: "Knobs are distracting, confusing and annoying. Personally, I'd rather things be 90% good 100% of the time than see 90 knobs." - Brad Fitzpatrick on having more than one Go scheduler. https://groups.google.com/forum/#!msg/golang-dev/eu0WzsTtNPo/pcD-zS3Jk

Re: High Availability command line interface - future plans.

On 8 November 2013 13:51, Gustavo Niemeyer wrote: > juju add-state-server --api-only-please-thanks And if we want to allow a machine that runs the environment-manager workers but not the api server or mongo server (not actually an unlikely thing given certain future possibilities) then add-state-

Re: High Availability command line interface - future plans.

juju add-state-server --api-only-please-thanks On Fri, Nov 8, 2013 at 11:43 AM, roger peppe wrote: > On 8 November 2013 13:33, Gustavo Niemeyer wrote: >> We'll end up with a command that adds a state server, with a replica >> of the database and an API server. That's the notion of state serve

Re: High Availability command line interface - future plans.

On 8 November 2013 13:33, Gustavo Niemeyer wrote: > We'll end up with a command that adds a state server, with a replica > of the database and an API server. That's the notion of state server > we've been using all along, and sounds quite reasonable, easy to > explain and understand. And when we

Re: High Availability command line interface - future plans.

We'll end up with a command that adds a state server, with a replica of the database and an API server. That's the notion of state server we've been using all along, and sounds quite reasonable, easy to explain and understand. On Fri, Nov 8, 2013 at 10:15 AM, roger peppe wrote: > On 8 November 20

Re: High Availability command line interface - future plans.

On 8 November 2013 12:03, Gustavo Niemeyer wrote: > Splitting API and db at some point sounds sensible, but it may be easy and > convenient to think about a state server as API+db for the time being. I'd prefer to start with a command name that implies that possibility; otherwise we'll end up eit

Re: High Availability command line interface - future plans.

On 8 November 2013 10:31, John Arbash Meinel wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2013-11-08 14:15, roger peppe wrote: >> On 8 November 2013 08:47, Mark Canonical Ramm-Christensen >> wrote: >>> I have a few high level thoughts on all of this, but the key >>> thing I wan

Re: High Availability command line interface - future plans.

On 8 November 2013 11:31, Gustavo Niemeyer wrote: > These are *very* good points, Mark. Taking them to heart will > definitely lead into a good direction for the overall feature > development. > > It sounds like we should avoid using a "management" command for > anything in juju, though. Most thin

Re: High Availability command line interface - future plans.

On Fri, Nov 8, 2013 at 9:39 AM, Nate Finch wrote: > If you only have 3 machines, do you really need HA from juju? You don't have > HA from your machines that are actually running your service. Why not? I have three machines.. > Yeah, same here. I still think we need a "turn on HA mode" command t

Re: High Availability command line interface - future plans.

On Fri, Nov 8, 2013 at 6:34 AM, Gustavo Niemeyer wrote: > On Fri, Nov 8, 2013 at 8:31 AM, John Arbash Meinel > wrote: > > I would probably avoid putting such an emphasis on "any machine can be > > a manager machine". But that is my personal opinion. (If you want HA > > you probably want it on ded

Re: High Availability command line interface - future plans.

These are *very* good points, Mark. Taking them to heart will definitely lead into a good direction for the overall feature development. It sounds like we should avoid using a "management" command for anything in juju, though. Most things in juju are about management one way or the other, so "juju

Re: High Availability command line interface - future plans.

On Fri, Nov 8, 2013 at 8:31 AM, John Arbash Meinel wrote: > I would probably avoid putting such an emphasis on "any machine can be > a manager machine". But that is my personal opinion. (If you want HA > you probably want it on dedicated nodes.) Resource waste holds juju back for the small users.

Re: High Availability command line interface - future plans.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-11-08 14:15, roger peppe wrote: > On 8 November 2013 08:47, Mark Canonical Ramm-Christensen > wrote: >> I have a few high level thoughts on all of this, but the key >> thing I want to say is that we need to get a meeting setup next >> week fo

Re: High Availability command line interface - future plans.

On 8 November 2013 08:47, Mark Canonical Ramm-Christensen wrote: > I have a few high level thoughts on all of this, but the key thing I want to > say is that we need to get a meeting setup next week for the solution to get > hammered out. > > First, conceptually, I don't believe the user model nee

Re: High Availability command line interface - future plans.

Given a bit of thought the reasons that I proposed the sub command remove-from rather than just remove are both obscure enough that I should have explained them, and wrong enough that I should not have proposed that syntax. I was thinking that remove always requires a machine ID, and that add did

Re: High Availability command line interface - future plans.

On Fri, Nov 8, 2013 at 4:47 PM, Mark Canonical Ramm-Christensen < mark.ramm-christen...@canonical.com> wrote: > I have a few high level thoughts on all of this, but the key thing I want > to say is that we need to get a meeting setup next week for the solution to > get hammered out. > > First, con

Re: High Availability command line interface - future plans.

I have a few high level thoughts on all of this, but the key thing I want to say is that we need to get a meeting setup next week for the solution to get hammered out. First, conceptually, I don't believe the user model needs to match the implementation model. That way lies madness -- users care

Re: High Availability command line interface - future plans.

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.

On 07/11/13 16:23, Marco Ceppi wrote: > On a final note, if namespacing does become a thing, can we /please /use > a unique character for the separation of namespace:service? A : would be > fantastic as calling something juju-db could very well be mistaken or > deployed as another service? `juju de

Re: High Availability command line interface - future plans.

Hi guys, I'm glad j...@lists.ubuntu.com got accidentally looped in because I may not have caught wind of this. I can understand both sides of the discussion, one where we provide more magic and the users trust that it works and the other where we leverage existing components and command structures

Re: High Availability command line interface - future plans.

On 07/11/13 15:00, Andrew Wilkins wrote: > On Thu, Nov 7, 2013 at 9:23 AM, Ian Booth > wrote: > > So, I haven't been involved directly in a lot of the discussion, but > my 2c is: > > +1 to juju ensure-ha > > Users don't give a f*ck about how Juju

Re: High Availability command line interface - future plans.

On 07/11/13 12:00, Andrew Wilkins wrote: > On Thu, Nov 7, 2013 at 9:23 AM, Ian Booth wrote: > >> So, I haven't been involved directly in a lot of the discussion, but my 2c >> is: >> >> +1 to juju ensure-ha >> >> Users don't give a f*ck about how Juju achieves HA, they just want to know >> their

Re: High Availability command line interface - future plans.

On Thu, Nov 7, 2013 at 9:23 AM, Ian Booth wrote: > So, I haven't been involved directly in a lot of the discussion, but my 2c > is: > > +1 to juju ensure-ha > > Users don't give a f*ck about how Juju achieves HA, they just want to know > their > data will survive a node outage. What Juju does und

Re: High Availability command line interface - future plans.

So, I haven't been involved directly in a lot of the discussion, but my 2c is: +1 to juju ensure-ha Users don't give a f*ck about how Juju achieves HA, they just want to know their data will survive a node outage. What Juju does under the covers to make that happen, what jobs are run on what node

Re: High Availability command line interface - future plans.

On Thu, Nov 7, 2013 at 5:54 AM, Tim Penhey wrote: > On 07/11/13 09:11, David Cheney wrote: > > +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: > >> > >> instead of adding more complexity an

Re: High Availability command line interface - future plans.

On 07/11/13 09:11, David Cheney wrote: > +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: >> >> instead of adding more complexity and concepts, it would be ideal if we >> could reuse the primitives w

Re: High Availability command line interface - future plans.

+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.

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.

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.

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.

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

High Availability command line interface - future plans.

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 f