<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Aug 9, 2014 at 11:19 AM, Stuart Bishop <span dir="ltr"><<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


I don't think this should be restricted to server reboots. The<br>
framework is generally useful.<br></blockquote><div><br></div><div>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.</div>


<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have hooks that need to bounce the primary service so config changes<br>
can take effect. They can't do that if a long running operation is<br>
currently in progress, eg. a backup or a replica node is being built.<br>
Currently, I need to block the hook until such time as I can proceed.<br>
I think this would be cleaner if I could instead return a particular<br>
error code from my hook, stating that it is partially complete and<br>
requesting it to be rescheduled.<br></blockquote><div><br></div><div>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).</div>


<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So it would be nice if requesting a reboot and requesting a hook to be<br>
rescheduled are independent things.<br></blockquote><div><br></div><div>+1 to this for sure.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I had wondered if juju-run should allow arbitrary things to be run in<br>
a hook context later.<br>
<br>
juju-run --after hook /sbin/reboot # queue the reboot command to be<br>
run after this hook completes.<br>
juju-run --after hook config-changed  # queue the config-changed hook<br>
to be run after this hook completes, and after any previously queued<br>
commands<br>
juju-run --after tomorrow report-status # Run the report-status<br>
command sometime after 24 hours.<br></blockquote><div><br></div><div>This *is* cool, but I have a few thoughts.</div><div><br></div><div>0) trivially,  don't think juju-run is the right spelling -- possibly juju-schedule?</div>
<div><br></div><div>1) I think that the reboot case is special enough not to be subsumed by that command.</div><div><br></div><div>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.</div>
<div><br></div><div>3) For this sort of schedule, might cron be a happier solution?</div><div><br></div><div>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?)</div>
<div><br></div><div>Cheers</div><div>William</div></div></div></div>