Implement system reboot via juju hooks

[Gabriel Samfira]

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: stuart at stuartbishop.net [stuart at stuartbishop.net] on behalf of Stuart Bishop [stuart.bishop at canonical.com]
Sent: Saturday, August 09, 2014 12:19 PM
To: Gabriel Samfira
Cc: juju-dev at lists.ubuntu.com
Subject: Re: Implement system reboot via juju hooks

On 8 August 2014 19:58, Gabriel Samfira <gsamfira at cloudbasesolutions.com> 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 <stuart.bishop at canonical.com>