High Availability command line interface - future plans.

[Marco Ceppi]

Hi guys,

I'm glad juju at 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 of juju
to provide this magic.

I have to agree with Kapil's point about add-unit/remove-unit syntax for
Juju HA. Having had to teach and demonstrate juju to quite a few people
now, juju is not an easy concept to grasp. Orchestration is really
something that people are just now starting to think about in general,
never mind how to wrap their heads around the concept and then furthermore
how we envision that concept, which is distilled in our product - juju. At
the end of the day I get it, we get it, it's easy for us because we're here
building it, but for the people out there it's a whole new language. If we
start off by saying "Oh, hey there, just run this ensure-ha command and
things will just be fantastic" is fine, but once you open up that route
it's going to be hard to back-peddle.

We already teach "Oh, your services is popular? Just `juju add-unit
<service>` magic will happen, units will fire, and you've scaled up. You've
added an additional available unit and you're safer than you were before".
Being able to convey the same strategy for when you want to safeguard and
make Juju's bootstrap a highly available service, the natural logic would
be to `juju add-unit`. In fact I was even asked this in a Charm School
recently, I'm paraphrasing but it was to some extent "Can I juju add-unit
bootstrap".

Since the majority of people seem to believe having the ultimate goal of
adding and removing juju specific services via a unique and reserved
namespace is a great goal to have it seems not shooting for that first
would simply introduce another awkward period of time which we have this
great feature but it's going to change soon so videos, blog posts, content
we produce to promote this shear awesomeness becomes stale and out of date
just as soon as the more "permanent" method of HA lands. For new users
learning a language this just becomes another hurtle to overcome in order
to be an expert and one more reason to look at something else other than
Juju.

Therefore, I (who really has no major say in this, simply because I'm not
capable of helping produce a solution) believe it's best to work for the
ultimate goal now instead of having to build a stop gap just to say we have
HA.

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 deploy some-random-thing juju-*` now we
have things sharing a special namespace that aren't actually special. (Like
juju-gui, though juju-gui is quite special and awesome, it's not "juju-"
core namespace special).

Thanks for all the awesome work you all do. I look forward to a solution,
whatever it may be, in the future!

Marco Ceppi


On Wed, Nov 6, 2013 at 9:22 PM, Tim Penhey <tim.penhey at canonical.com> wrote:

> On 07/11/13 15:00, Andrew Wilkins wrote:
> > On Thu, Nov 7, 2013 at 9:23 AM, Ian Booth <ian.booth at canonical.com
> > <mailto:ian.booth at canonical.com>> 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 under the covers to
> >     make that
> >     happen, what jobs are run on what nodes etc - that's for Juju to
> >     care about.
> >
> >
> > I'm not so sure about that. I expect there'll be users who wants to know
> > *exactly* how it works, because otherwise they won't feel they can trust
> > it with their services. That's not to say that ensure-ha can't be
> > trusted - just that some users will want to know what it's doing under
> > the covers. Speculative, but based on past experience with banks,
> > insurance companies, etc.
>
> I think if we gave no feedback at all, then yes, this would feel like
> magic.  However, I'd expect us to at least say what we are doing on the
> command line :-)
>
> I think ensure-ha is sufficient for a first cut, and a way to get ha on
> a running system.
>
> For the record, we discussed the default behaviour for ensure-ha was to
> make three nodes of manager services.  The user could override this by
> specifying "-n 5" or "-n 7", or some other odd number.
>
> > Another thing to consider is that one person's HA is not the next
> > person's. I may want to disperse my state servers across multiple
> > regions (were that supported); you might find this costs too much in
> > inter-region traffic. What happens if I have a temporary outage in one
> > region - where does ensure-ha automatically spin up a new one? What
> > happens when the original comes back? Each of these things are things
> > people may want to do differently, because they each have different
> > trade-offs.
>
> I agree that support over regions is an important idea, but this is way
> outside the scope of this HA discussion.
>
> AFAIK, our cross-region story is still all about cross-environment
> relations, not spanning regions with one environment.
>
> Tim
>
> --
> 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/20131106/2896d1ac/attachment-0001.html>