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
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
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
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
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,
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
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
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
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
>
>
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
10 matches
Mail list logo