High Availability command line interface - future plans.

Fri Nov 8 08:47:51 UTC 2013

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 about the things
they care about and should not have to understand how the system works to
get something basic done. See:
http://www.amazon.com/The-Inmates-Are-Running-Asylum/dp/0672326140 for
reasons why I call this madness.

For that reason I think the path of adding a --jobs flag to add-machine is
not a move forward.  It is exposing implementation detail to users and
forcing them into a more complex conceptual model.

Second, we don't have to boil the ocean all at once. An "ensure-ha" command
that sets up additional server nodes is better than what we have now --
nothing.  Nate is right, the box need not be black, we could have an juju
ha-status command that just shows the state of HA.   This is fundamentally
different than changing the behavior and meaning of add-machines to know
about juju jobs and agents and forcing folks to think about that.

Third, we I think it is possible to chart a course from ensure-ha as a
shortcut (implemented first) to the type of syntax and feature set that
Kapil is talking about.  And let's not kid ourselves, there are a bunch of
new features in that proposal:

 * Namespaces for services
 * support for subordinates to state services
 * logging changes
 * lifecycle events on juju "jobs"
 * special casing the removal of services that would kill the environment
 * special casing the stats to know about HA and warn for even state server
nodes

I think we will be adding a new concept and some new syntax when we add HA
to juju -- so the idea is just to make it easier for users to understand,
and to allow a path forward to something like what Kapil suggests in the
future.   And I'm pretty solidly convinced that there is an incremental
path forward.

Fourth, the spelling "ensure-ha" is probably not a very good idea, the
cracks in that system (like taking a -n flag, and dealing with failed
machines) are already apparent.

I think something like Nick's proposal for "add-manager" would be better.
Though I don't think that's quite right either.

So, I propose we add one new idea for users -- a state-server.

then you'd have:

juju management --info
juju management --add
juju management --add --to 3
juju management --remove-from

I know this is not following the add-machine format, but I think it would
be better to migrate that to something more like this:

juju machine --add

--Mark Ramm

On Thu, Nov 7, 2013 at 8:16 PM, roger peppe <roger.peppe at canonical.com>wrote:

> On 6 November 2013 20:07, Kapil Thangavelu
> <kapil.thangavelu at canonical.com> 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 and therefore are omitted by default from status listing.
> > That's a much simpler story to document. how do i scale my state server..
> > juju add-unit juju-db... my provisioner juju add-unit juju-provisioner.
>
> I have a lot of sympathy with this point of view. I've thought about
> it quite a bit.
>
> I see two possibilities for implementing it:
>
> 1) Keep something like the existing architecture, where machine agents can
> take on managerial roles, but provide a veneer over the top which
> specially interprets service operations on the juju built-in services
> and translates them into operations on machine jobs.
>
> 2) Actually implement the various juju services as proper services.
>
> The difficulty I have with 1) is that there's a significant mismatch
> between
> the user's view of things and what's going on underneath.
> For instance, with a built-in service, can I:
>
> - add a subordinate service to it?
> - see the relevant log file in the usual place for a unit?
> - see its charm metadata?
> - join to its juju-info relation?
>
> If it's a single service, how can its units span different series?
> (presumably it has got a charm URL, which includes the series)
>
> I fear that if we try this approach, the cracks show through
> and the result is a system that's hard to understand because
> too many things are not what they appear.
> And that's not even going into the plethora of special
> casing that this approach would require throughout the code.
>
> 2) is more attractive, as it's actually doing what's written on the
> label. But this has its own problems.
>
> - it's a highly significant architectural change.
>
> - juju managerial services are tightly tied into the operation
> of juju itself (not surprisingly). There are many chicken and egg
> problems here - we would be trying to use the system to support itself,
> and that could easily lead to deadlock as one part of the system
> tries to talk to another part of the system that relies on the first.
> I think it *might* be possible, but it's not gonna be easy
> and I suspect nasty gotchas at the end of a long development process.
>
> - again there are inevitably going to be many special cases
> throughout the code - for instance, how does a unit
> acquire the credentials it needs to talk to the API
> server?
>
> It may be that a hybrid approach is possible - for example
> implementing the workers as a service and still having mongo
> and the API server as machine workers. I think that's
> a reasonable evolutionary step from the approach I'm proposing.
>
>
> The reasoning behind my proposed approach perhaps
> comes from the fact that (I'm almost ashamed to admit it)
> I'm a lazy programmer. I don't like creating mountains of code
> where a small amount will do almost as well.
>
> Adding the concept of jobs on machines maps very closely
> to the architecture that we have today. It is a single
> extra concept for the user to understand - all the other
> features (e.g. add-machine and destroy-machine) are already
> exposed.
>
> I agree that in an ideal world we would scale juju meta-services
> just as we would scale normal services, but I think it's actually
> reasonable to have a special case here.
>
> Allowing the user to know that machines can take on juju managerial
> roles doesn't seem to be a huge ask. And we get just as much
> functionality with considerably less code, which seems like a significant
> win to me in terms of ongoing maintainability and agility for the future.
>
>   cheers,
>     rog.
>
> PS apologies; my last cross-post, honest! followups to
> juju-dev at lists.ubuntu.com only.
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20131108/e251264e/attachment.html>