High Availability command line interface - future plans.

[roger peppe]

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 represents a design goal and fill out its
implementation until it meets that goal.

In this discussion, "ensure-ha" seems to me to epitomise the second
approach and I do understand the arguments for it. With reference to
Mark's mention of "the inmates running the asylum", I realise that, by
that analogy, I am most certainly an inmate here. My ideas about what
might make for a solid and straightforward tool to use are biased by my
knowledge of the structure of the system.

William's response is clear, so ensure-ha it is.  I'm afraid we're back
where we started but I've found this conversation useful and hope that
others have too.

> I don't have the will to bike-shed around the actual command we use,
> however I strongly suggest that we go with something that makes sense to
> Jorge and Marco (and to our CTS folks) as they are our people on the
> ground, using this tool.

It would have been great to have had feedback from the CTS folks (possibly
the biggest current operational users of Juju?) for their views.

  cheers,
    rog.

On 11 November 2013 03:50, Tim Penhey <tim.penhey at canonical.com> wrote:
> On 09/11/13 03:04, roger peppe wrote:
>> On 8 November 2013 13:51, Gustavo Niemeyer <gustavo at niemeyer.net> 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-server is a command that
>> doesn't necessarily add a state server at all... That thought
>> was the source of my doubt.
>
> I think that it is reasonable to think of just the db and the api server
> from the user's point of view.
>
> The fact that we may run other workers along side the api server is up
> to us, and not something we actually need to expose to people.
>
> Most of our users should have no problem at all understanding juju:db
> and juju:api (or whatever names we call them).
>
>> That said, it's just a spelling. If there's general agreement on "state-server",
>> so be it - I'm very happy to move forward with that.
>
> I cringe whenever I see "state" used anywhere.
>
> I would like use to move towards namespaced services with a common
> understanding, but I'm happy to have that significantly down the line.
>
> Just remember that whatever command we come up with, it needs to be
> easily explained to our new users.  I like the idea of a special command
> that handles the HA-ness of juju, because it means we can give
> meaningful error messages when people do things not quite right (like
> adding just one more mongo db thinking it is enough).
>
> I don't have the will to bike-shed around the actual command we use,
> however I strongly suggest that we go with something that makes sense to
> Jorge and Marco (and to our CTS folks) as they are our people on the
> ground, using this tool.
>
> Cheers,
> Tim
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev