On Fri, Feb 19, 2016 at 6:30 PM, Charles Butler <charles.but...@canonical.com> 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 an @after() that i can ensure will be run before/after > any workloads have landed on that daemon. > > Thats been a recurring headache for me is trying to figure out how to stuff > that in without doing some serious state wizardry in the base layer i'm > providing for workloads to consume. > > +1 to that
+1 > > > Charles Butler <charles.but...@canonical.com> - Juju Charmer > Come see the future of modeling your datacenter: http://jujucharms.com > > On Fri, Feb 19, 2016 at 8:52 AM, Stuart Bishop <stuart.bis...@canonical.com> > wrote: >> >> On 19 February 2016 at 16:32, Merlijn Sebrechts >> <merlijn.sebrec...@gmail.com> 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 is processed. >> > Events >> > can be processed by multiple handlers or by none, and in both cases they >> > become irrelevant after the single point in time. >> >> > So what I'm getting at is this: >> > >> > - Handlers with event decorators may only be queued immediately after >> > the >> > event has fired >> > - Events do not get retested in the queue >> > - States work as they do now >> >> Apart from a file changing, what 'events' happen in the middle of a >> hook that shouldn't remain set for the remainder of the hook? I can't >> come up with any valid use cases, so maybe this all becomes a case of >> fixing @when_file_changed rather than adding new stuff. >> >> That said, if there are valid use cases, perhaps an @after decorator. >> It would work like @when, except it would remain active until the >> handler has been run. ie. @when('foo') might get dequeued if the 'foo' >> state is removed, but the @after('foo') would remain on the queue even >> if the 'foo' state is removed. If a handler was decorated by both >> @after('foo') and @when('bar'), it could get queued when 'bar' is set >> even if 'foo' has since been removed. It seems easy enough to >> implement (just a new decorator - no need to change the reactor), and >> the same approach could be used to implement a fixed >> @when_file_changed. >> >> (You could even implement @after in your charm or in a 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
