High Availability command line interface - future plans.

Fri Nov 8 11:31:19 UTC 2013

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 management" becomes very unclear and hard
to search for.

Instead, the command might be named after what we've been calling them:

    juju add-state-server -n 2

For implementation convenience sake, it would be okay to only ever
accept -n 2 when this is first released. I can also imagine the
behavior of this command resembling add-unit in a few aspects, since a
state server is in fact code that just needs a home to run in. This
may yield other common options across them, such as machine selection.

On Fri, Nov 8, 2013 at 6:47 AM, Mark Canonical Ramm-Christensen
<mark.ramm-christensen at 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, 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
>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>

-- 

gustavo @ http://niemeyer.net