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.jo...@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.bis...@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.bis...@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.bis...@canonical.com> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> > > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju > >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
