Implement system reboot via juju hooks

[William Reade]

On Sat, Aug 9, 2014 at 11:19 AM, Stuart Bishop <stuart.bishop at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140811/7c9d768c/attachment.html>