=== frankban|afk is now known as frankban === ed is now known as Guest32400 [15:27] I have some resource questions [15:28] * skay has multiple questions and is now stuck deciding which one to ask first [15:29] I want to do upgrades and installs based on the availability of a resource. I have something that checks for the existence or change of a resource and sets a state [15:30] I can have @when_not checking that state for me, so that it triggers an install or upgrade [15:31] but, I can also have that check inside of the upgrade hook, because in the docs, the resource section says that juju attach triggers the upgrade [15:31] which is a better design or are they the same, or is there another approach you'd suggest? [15:33] another question. why isn't there a hook specific to juju attach? [15:41] also, it would be handy to have a decorator for when a resource changes. I could use @when_file_changed for this, but it means I would need to pass a callback that gets the resource of interest and returns its path. Is that a discouraged approach compared to soemthing that sets a flag? [15:43] also, I can check this in the src code later, but if someone knows off the top of their head it would be useful... The docs mentioned that juju attach triggers the upgrade-charm hook, but do not specify whether juju deploy in conjunction with a resource flag does [15:44] s/flag/option [16:18] "another question. why isn't there a hook specific to juju attach?" - let me see if I can find the mailing list post I sent out for this, possibly you can put heat on it [16:20] skay: https://lists.ubuntu.com/archives/juju/2017-September/009515.html [16:37] bdx: ack. just followed up [16:37] thanks [16:38] whoops, I replied all and I'm not subscribed to juju-dev [16:40] skay: I just got your email [16:40] you might get a bounce back from juju-dev though [16:40] bdx: I kept it pretty short [16:40] I did [16:44] skay: I feel like the decorator would be serving a similar purpose as a upgrade-resource-myresource hook though right [16:44] yes [16:44] we just need something decoupled from the upgrade-charm hook [16:44] I agree with that part === frankban is now known as frankban|afk [16:45] I'm not sure whether hooks are preferred over reactive flags [16:45] s/reactive flags/reactions? [16:49] skay: yeah so, using the reactive framework, you set and unset "flags" that cause your "reactive handlers" to fire when the sufficient rules are met [16:49] correct [16:50] skay: hooks are the underlying mechanism (legacy juju 1 uses these) that we are abstracting away by using the reactive framework on top [16:51] correct, so I thought it followed that the recommend way for charmers going forward is to avoid using hooks and to use flags [16:51] and the reactive decorators [16:51] entirely [16:51] this is why I want a decorator like resource-changed [16:51] or for a resource being attached [16:53] skay: I see what you are saying .... my suggestion of having an upgrade-resource-myresource hook is dealing with legacy-ish juju [16:54] skay: so possibly I misspoke, it should be a upgrade-resource-myresource flag that is set upon resource upgrade/attach [16:54] I see. btw, wouldn't it be simpler to have an upgrade-resource hook rather than creating hooks on the fly? [16:54] not sure I follow [16:56] I think I misunderstood. do you want @upgrade_resource("myresource") ? [16:57] I'm chasing the capability to handle a resources' lifecycle ops on an per-resource basis [16:57] skay: @when('upgrade-resource-myresource') [16:57] or for juju to discover the resourses from the charm and create @upgrade_resource_myresource() based on the resources listed [16:58] that makes more sense than what I thouhgt you meant [16:58] ha [16:58] awesome [16:58] yeah, something similar to https://github.com/jamesbeedy/interface-db-info/blob/master/provides.py#L9 [16:59] how the interface hooks are generated there [20:19] is normal that juju stucks in waiting for address?