Hi Bishop, What you are describing sounds like a scheduling framework. While that is a great feature to have, it goes beyond the scope of what I am trying to achieve. I agree that rescheduling a hook to be run later can be useful in more then the context I am describing, but the change I am proposing assumes that the unit agent and/or the machine agent will soon be restarted, thus rerunning the queued hook.
I can implement the re-queueing of the hook and the reboot as a separate feature, but in cases where a reboot does not happen, we would then have to decide how exactly the re-queued hook will be run. In essence, we need to figure out, what an appropriate trigger would be for starting the hook again. I believe a blueprint for a scheduling framework would be great, and we could definitely evolve what I am proposing into such a feature later on. Regards, Gabriel ________________________________________ From: [email protected] [[email protected]] on behalf of Stuart Bishop [[email protected]] Sent: Saturday, August 09, 2014 12:19 PM To: Gabriel Samfira Cc: [email protected] Subject: Re: Implement system reboot via juju hooks 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
