leader-set immediately writes the key/value pairs to the state server,
which will then inform non-leader units of the change. It will fail if called
without arguments, or if called by a unit that is not currently service leader.
leader-set acts much like relation-set, in that it lets
you write string key/value pairs (in which an empty value removes the key), but
with the following differences:
* there's only one leader-settings bucket per service (not one per unit)
* only the leader can write to the bucket
* only minions are informed of changes to the bucket
* changes are propagated instantly, bypassing the sandbox
The instant propagation may be surprising, but it exists to satisfy the use case where shared data can be chosen by the leader at the very beginning of (say) the install hook. By propagating it instantly, any running followers can make use of the data and progress immediately, without having to wait for the leader to finish its hook.
It also means that you can guarantee that a successful leader-set call has
been reflected in the database, and that all follower will converge towards
seeing that value, even if an unexpected error takes down the current hook.
For both these reasons it is strongly recommended that leader settings are
always written as a self-consistent group (leader-set foo=bar baz=qux ping=pong,
rather than leader-set foo=bar; leader-set baz=qux etc, to avoid situations
where minions may end up seeing a sandbox in which only foo is set to the
"correct" value).