Re: @when('config.changed')

2016-02-20 Thread Antoni Segura Puimedon
On Fri, Feb 19, 2016 at 6:30 PM, Charles Butler wrote: > I like the idea of an @after() decorator. > > I've run into some cases where having @after would be a boon, such as > cycling for docker extensions (setting up network, storage, et-al) that > would benefit from

Re: @when('config.changed')

2016-02-19 Thread Stuart Bishop
On 19 February 2016 at 16:32, Merlijn Sebrechts wrote: > I completely agree with you on point two. The semantics I'm trying to get at > for point one are a bit different. Events are information that is relevant > for a single point in time, not until the information

Re: @when('config.changed')

2016-02-19 Thread Merlijn Sebrechts
Hi Ben I completely agree with you on point two. The semantics I'm trying to get at for point one are a bit different. Events are information that is relevant for a single point in time, not until the information is processed. *Events can be processed by multiple handlers or by none, and in both

Re: @when('config.changed')

2016-02-18 Thread Benjamin Saller
I really appreciate this kind of thinking, looking for root causes is the hallmark of better systems design. That said I'd suggest the difference between _event_ and _state_ as you describe them are really only a usage convention around the same abstraction. The semantics you seem to be pointing

Re: @when('config.changed')

2016-02-17 Thread Stuart Bishop
uld have been another state named something like config.initial. @when('config.changed') def first_hook_and_config_changed(): pass @when('config.changed') @when_not('config.initial') def config_changed_not_first_hook(): pass > This provides a much cleaner way of detecting changes to config,

Re: @when('config.changed')

2016-02-17 Thread Marco Ceppi
On Wed, Feb 17, 2016 at 5:56 PM Matt Bruzek wrote: > I hate to go against the love-in here. While I desperately want a > configuration changed feature for the reactive framework. I disagree with > the way it was implemented. I brought up issues with this

Re: @when('config.changed')

2016-02-17 Thread Matt Bruzek
I hate to go against the love-in here. While I desperately want a configuration changed feature for the reactive framework. I disagree with the way it was implemented. I brought up issues with this implementation in the pull request: https://github.com/juju-solutions/layer-basic/pull/36 It feels

Re: @when('config.changed')

2016-02-17 Thread Nick Moffitt
That's a very good point. Marco Ceppi: > Relations are best served being managed by the interface layer. Which > should consume the data and raise states as appropriate. > > On Wed, Feb 17, 2016 at 3:45 PM Nick Moffitt > wrote: > > > Cory Johns: > > > If a charm

Re: @when('config.changed')

2016-02-17 Thread Tom Barber
Cool! I'll work that into my charms tomorrow. Might as well go all out on the new stuff ;) Tom On 17 Feb 2016 18:48, "Marco Ceppi" wrote: > This is awesome, glad to see this wrapped in the reactive framework. Will > make a lot of my layers much simpler! > > Marco > >

@when('config.changed')

2016-02-17 Thread Cory Johns
Just wanted to give a heads-up about a feature that landed in the reactive base layer yesterday. If a charm config option has changed, the state "config.changed" will be set for the duration of the hook. Additionally, specific states will be set for each config option that changed; that is, if