Re: Leadership layer released

On 28 January 2016 at 21:42, Cory Johns wrote: > 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

Re: Leadership layer released

Hi Marco Just to be clear, I was talking about wrapping the code to set a state that shows if something changed. I wasn't sure how to implement this. States are saved across hook invocations but 'x.changed' should be removed at the end of a hook invocation. Stuart's code solves this problem by

Re: Leadership layer released

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...

Re: Leadership layer released

On 28 January 2016 at 22:47, Merlijn Sebrechts wrote: > Hi Marco > > > Just to be clear, I was talking about wrapping the code to set a state that > shows if something changed. I wasn't sure how to implement this. States are > saved across hook invocations but

Re: Leadership layer released

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

Leadership layer released

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