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 Charles Butler <[email protected]> - Juju Charmer Come see the future of modeling your datacenter: http://jujucharms.com On Fri, Feb 19, 2016 at 8:52 AM, Stuart Bishop <[email protected]> wrote: > On 19 February 2016 at 16:32, Merlijn Sebrechts > <[email protected]> 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 <[email protected]> > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
