Leadership layer released

Thu Jan 28 15:33:38 UTC 2016

I agree, I was just mulling over how to document all of these layers,
something we all should discuss in Belgium at the Summit. As for wrapping,
you shouldn't really need to wrap it since it's just a layer!

Awesome job with this layer, loving its implementation!

On Thu, Jan 28, 2016 at 10:29 AM Merlijn Sebrechts <
merlijn.sebrechts at gmail.com> wrote:

> These 'changed.x' states are really useful! I wanted something like this
> in my own layers, but I wasn't sure on how to implement it..
>
> It might be good to include this in the docs? Or maybe write a nice
> wrapper around this logic so it can be easily used in other layers? I know
> I will use it...
>
> 2016-01-28 15:42 GMT+01:00 Cory Johns <cory.johns at canonical.com>:
>
>> This is awesome.  A very clean interface for dealing with leadership in
>> layered charms.
>>
>> I also very much like the pattern of having states that notify of changes
>> to the leadership settings and think this pattern could apply well to
>> config settings.  One addition I would suggest to that pattern would be to
>> also have a blanket `leadership.changed` state that would be set when *any*
>> value was changed.  This is mostly to handle the case where you need to
>> react to any of a set of multiple values changing.  Thoughts?
>>
>> Thanks for creating this!
>>
>> On Wed, Jan 27, 2016 at 11:35 PM, Stuart Bishop <
>> stuart.bishop at canonical.com> wrote:
>>
>>> Hi.
>>>
>>> I've put up my Leadership layer on http://interfaces.juju.solutions/.
>>> This work was broken out from my PostgreSQL charm refactorings and
>>> will also be used by the Cassandra charm when I get onto that. It is
>>> obviously small and focused on leadership; I had been considering
>>> consolidating a number of similar parts into a swiss army knife
>>> 'hookenv' layer, but decided that smaller bricks are more in the
>>> spirit of layered charms and avoids most feature creep.
>>>
>>> # Leadership Layer for Juju Charms
>>>
>>> The Leadership layer is for charm-tools and 'charm build', making it
>>> easier for layered charms to deal with Juju leadership.
>>>
>>> This layer will initialize charms.reactive states, allowing you to
>>> write handlers that will be activated by these states. It allows you
>>> to completely avoid writing leader-elected and leader-settings-changed
>>> hooks. As a simple example, these two handlers are all that is required
>>> to make the leader unit generate a password if it is not already set,
>>> and have the shared password stored in a file on all units:
>>>
>>> ```python
>>> from reactive.leadership import leader_get, leader_set
>>> from charmhelpers.core.host import pwgen
>>>
>>>
>>> @when('leadership.is_leader')
>>> @when_not('leadership.set.admin_password')
>>> def generate_secret():
>>>     leader_set(admin_password=pwgen())
>>>
>>>
>>> @when('leadership.changed.admin_password')
>>> def store_secret():
>>>     write_file('/etc/foopass', leader_get('admin_password'))
>>> ```
>>>
>>>
>>> ## States
>>>
>>> The following states are set appropriately on startup, before any @hook
>>> decorated methods are invoked:
>>>
>>>     * `leadership.is_leader`
>>>
>>>       This state is set when the unit is the leader. The unit will remain
>>>       the leader for the remainder of the hook, but may not be leader in
>>>       future hooks.
>>>
>>>     * `leadership.set.{varname}`
>>>
>>>       This state is set for each leadership setting (ie. the
>>>       `leadership.set.foo` state will be set if the leader has set
>>>       the foo leadership setting to any value). It will remain
>>>       set for the remainder of the hook, unless the unit is the leader
>>>       and calls `reactive.leadership.leader_set()` and resets the value
>>>       to None.
>>>
>>>     * `leadership.changed.{varname}`
>>>
>>>       This state is set for each leadership setting that has changed
>>>       since the last hook. It will remain set for the remainder of the
>>>       hook. It will not be set in the next hook, unless the leader has
>>>       changed the leadership setting yet again.
>>>
>>>
>>> ## Methods
>>>
>>> The `reactive.leadership` module exposes the `leader_set()` and
>>> `leader_get()` methods, which match the methods found in the
>>> `charmhelpers.core.hookenv` module. `reactive.leadership.leader_set()`
>>> should be used instead of the charmhelpers function to ensure that
>>> the reactive state is updated when the leadership settings are. If you
>>> do not do this, then you risk handlers waiting on these states to not
>>> be run on the leader (because when the leader changes settings, it
>>> triggers leader-settings-changed hooks on the follower units but
>>> no hooks on itself).
>>>
>>>
>>> ## Support
>>>
>>> This layer is maintained on Launchpad by
>>> Stuart Bishop (stuart.bishop at canonical.com).
>>>
>>> Code is available using git at git+ssh://
>>> git.launchpad.net/leadership-layer.
>>>
>>> Bug reports can be made at https://bugs.launchpad.net/leadership-layer.
>>>
>>> Queries and comments can be made on the Juju mailing list, Juju IRC
>>> channels, or at https://answers.launchpad.net/leadership-layer.
>>>
>>>
>>> --
>>> Stuart Bishop <stuart.bishop at canonical.com>
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160128/54131c45/attachment.html>