Charm derivation

[Gustavo Niemeyer]

> Right, I think we should probably change the term from "leader" to
> "actor", as what we're really trying to choose is not the authoritative
> leader of an action, but just the most efficient choice to perform an
> action right now. Its entirely possible that between the time your hook
> has started doing said action, and the time it is finished, juju may
> think you have left the cluster and told all the other units about that.
> In the CEPH case, we're still relying on CEPH to broker this action. In
> the shared key case, we're accepting that the key might change. This is
> not so much a leader, but just the current best choice.

I'm not in a position to evaluate what the logic you implemented
without further research, but as far as you're conscious that the
selected unit is random and there may be multiple units that believe
they should be doing something, it sounds ok.

> This makes me wonder if we shouldn't just spin up a service inside
> the units and implement our own leader election within these charm
> helpers. Sure this is an inefficient thing to do given juju's abilities
> to do it at a low level using ZK, but something we could do as a PoC,
> and when a few charms are written relying on this inefficiency, we can
> move the priority a bit higher in juju.

I'm not going to hold you back from doing something you believe is
useful to you, as you're in a better position to tell where to invest
your own time.

What I can say is that I want juju to support leader election
eventually, internally and simply, because people often get it wrong
and end up with solutions that elect multiple leaders in some cases,
and none in other cases, which kills the reason for doing leader
election, and we're in a good position to implement this logic because
a lot of the stuff juju does is offering concurrency in a sane(r) way.

-- 
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/plus
http://niemeyer.net/twitter
http://niemeyer.net/blog

-- I'm not absolutely sure of anything.