On 8 August 2014 19:58, Gabriel Samfira <[email protected]> wrote: > Hello folks! > > I would like to start work on implementing reboots via juju hooks. I > have outlined in a google docs document a few thoughts regarding why > this is needed and some implementation details I would like to discuss > before starting. > > You may find the doc here: > > http://goo.gl/tGoIuM > > Any thoughts/suggestions are welcome. > > Gabriel
I don't think this should be restricted to server reboots. The framework is generally useful. 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. So it would be nice if requesting a reboot and requesting a hook to be rescheduled are independent things. 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. -- Stuart Bishop <[email protected]> -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
