On Sat, Aug 9, 2014 at 11:19 AM, Stuart Bishop <stuart.bis...@canonical.com> wrote: > > I don't think this should be restricted to server reboots. The > framework is generally useful. >
I agree that it's generally useful to be able to defer running things in a hook context, but I'd prefer to keep this tightly scoped if possible. I have hooks that need to bounce the primary service so config changes > can take effect. They can't do that if a long running operation is > currently in progress, eg. a backup or a replica node is being built. > Currently, I need to block the hook until such time as I can proceed. > I think this would be cleaner if I could instead return a particular > error code from my hook, stating that it is partially complete and > requesting it to be rescheduled. > I definitely agree that having to block inside hooks is tedious and generally unhelpful (other units, for example, cannot run their own independent hooks; machine agents can't (safely) apt-get anything). So it would be nice if requesting a reboot and requesting a hook to be > rescheduled are independent things. > +1 to this for sure. I had wondered if juju-run should allow arbitrary things to be run in > a hook context later. > > juju-run --after hook /sbin/reboot # queue the reboot command to be > run after this hook completes. > juju-run --after hook config-changed # queue the config-changed hook > to be run after this hook completes, and after any previously queued > commands > juju-run --after tomorrow report-status # Run the report-status > command sometime after 24 hours. > This *is* cool, but I have a few thoughts. 0) trivially, don't think juju-run is the right spelling -- possibly juju-schedule? 1) I think that the reboot case is special enough not to be subsumed by that command. 2) I'm not clear on the benefit of constructing an additional charm-driven hook queue, and I worry that it would make the actual operation of the unit agent alarmingly opaque -- interaction with error states, interaction with charm upgrades, confusion due to other hooks jumping the queue, etc. 3) For this sort of schedule, might cron be a happier solution? I'd like to explore your use cases a bit more to see if we can find a clean solution to your problems that doesn't go too far down the (2) road that I'm nervous about. (The try-again-later mechanism is much smaller and cleaner and I think we can accommodate that one pretty easily, fwiw -- but what are the other problems you want to solve?) Cheers William
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
