<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 20, 2016 at 8:46 AM, Stuart Bishop <span dir="ltr"><<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 20 January 2016 at 13:17, John Meinel <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>> wrote:<br>
<br>
> There are classes of failures that a charm hook itself cannot handle. The<br>
> specific one Bogdan was working with is the fact that the machine itself is<br>
> getting restarted while the charm is in the middle of processing a hook.<br>
> There isn't any way the hook itself can handle that, unless you could raise<br>
> a very specific error that indicates you should be retried (so as it notices<br>
> its about to die, it raises the try-me-again error).<br>
><br>
> Hooks are supposed to be idempotent regardless, aren't they? So while we<br>
> paper over transient bugs in them, doesn't it make the system more resilient<br>
> overall?<br>
<br>
</span>The new update-status hook could be used to recover, as it is called<br>
automatically at regular intervals. If the reboot really was random,<br>
you would need to clear the error status first. But if it is triggered<br>
by the charm, it is just a case of 'reboot(now+30s);<br>
status_set('waiting', 'Waiting for reboot'); sys.exit(0)' and waiting<br>
for the update-status hook to kick in.<br></blockquote><div><br></div><div>If it's triggered by the charm, it should `juju-reboot`, which will bounce the machine after the hook is committed (or, with `--now`, do so right away and requeue the executing hook). Regardless, from a charm's perspective, "random" reboots will happen, as will an arbitrary number of other "random" failures that really aren't worth a stop-the-line response.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It happens naturally if you structure your charm to have a single hook<br>
that does everything that needs to be done, rather than trying to<br>
craft individual hooks to deal with specific events.<br></blockquote><div><br></div><div>Independent of everything else, *this* should *excellent* advice for speeding up your deployments. Have you already been writing charms like this? I'd love to hear your experiences; and, in particular, if you've noticed any improvement in deployment speed. The theoretically achievable speedup is vast, but the hook runner wasn't written with this approach in mind; we might need to make a couple of small tweaks [0] to get the best out of the approach.</div><div><br></div><div>Cheers</div><div>William</div><div> </div><div>[0] basically, check for hook existence *before* doing all the context setup work. It's essentially a no-brainer, but it's not quite trivial to do, and has just never hit the top of anyone's list.</div><div><br></div></div></div></div>