Juju Leader Election and Application-Specific Leadership

[Andrew Wilkins]

On Wed, Apr 5, 2017 at 10:26 PM Dmitrii Shcherbakov <
dmitrii.shcherbakov at canonical.com> wrote:

> Hi everybody,
>
> I have a question with regards to Juju leader unit election and
> application-specific leadership.
>
> https://jujucharms.com/docs/2.1/reference-charm-hooks#leader-elected
> "leader-elected is run at least once to signify that Juju decided this
> unit is the leader. Authors can use this hook to take action if their
> protocols for leadership, consensus, raft, or quorum require one unit
> to assert leadership. If the election process is done internally to
> the service, other code should be used to signal the leader to Juju.
> For more information read the charm leadership document."
>
> This doc says
> "If the election process is done internally to the service, other code
> should be used to signal the leader to Juju.".
>

My understanding of this sentence is this: Juju's internal leadership
election, and your application's leadership election, are entirely
orthogonal.

Longer: if your application has its own internal leadership election, then
you may wish to present the name of the leader to the user (or other
applications), e.g. using application status or relation data. That's what
I take "other code" to mean.

That could be made clearer.

Cheers,
Andrew

However, I don't see any hook tools to assert leadership to Juju from
> a charm based upon application-specific leadership information
> http://paste.ubuntu.com/24319908/
>
> So, as far as I understand, there is no manual way to designate a
> leader and the doc is wrong.
>
> Does anyone know if it is supposed to be that way and if this has not
> been implemented for a reason?
>
> It might be tricky to implement as if you have a network partition you
> may actually have multiple application-level leaders in separated
> clusters. If Juju has access to both clusters (say, via a management
> network) but applications themselves cannot reach each other, it may
> get conflicting requests for leadership from that "other code that
> should be used to signal the leader to Juju".
>
> The "require one unit to assert leadership" part does make sense - if
> an application supports a manual leader specification then you can
> rely on Juju to pick a leader unit which will have code to set a
> leader manually via application's own tools on leader-elected event.
>
> In other words, I can see how it works for
>
> juju leader unit configured -> application-specific leader configured
>
> scenario, but not for
>
> juju leader unit configured <- 'custom code' <- application-specific
> leader configured
>
> Doing a pickaxe search for a part of the above doc reveals that this
> has originally been pushed into the juju docs repo in 2015.
>
> ➜  docs git:(master) git log -S '`leader-elected` run at least once to'
>
> commit 2868eebe2abf2019a39b1dba56487ef22adc648d
> ...
> Date:   Tue Aug 30 08:13:56 2016 -0500
>
>     added missing hooks
>
> commit 7df18e4f11350077c88e40d560a6f34911cd34f4
> ...
> Date:   Thu Nov 12 16:16:48 2015 -0600
>
>     Adding the reference for charm hooks and links to it.
>
> commit 7d94261f4ae3541bb1af93707414102c81515b43
> ...
> Date:   Thu Nov 12 16:16:48 2015 -0600
>
>     Adding the reference for charm hooks and links to it.
>
> ----
>
> Does anyone know the current official stance on this?
>
> Thanks in advance!
>
> Best Regards,
> Dmitrii Shcherbakov
>
> Field Software Engineer
> IRC (freenode): Dmitrii-Sh
>
> --
> 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/20170406/cdb0518e/attachment.html>