<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 11 August 2014 13:48, Andrew Wilkins <span dir="ltr"><<a href="mailto:andrew.wilkins@canonical.com" target="_blank">andrew.wilkins@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Mon, Aug 11, 2014 at 5:41 AM, Menno Smits <span dir="ltr"><<a href="mailto:menno.smits@canonical.com" target="_blank">menno.smits@canonical.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">How this happens is slightly complex but the short answer is that if any of jujud's workers exit with a fatalError (as defined in cmd/jujud/agent.go), then jujud will terminate (and then be restarted by upstart).<div>


<br></div><div>I'm not sure how you should propagate the need to exit from the restore API call through to the worker but I'm sure that's doable.</div></div></blockquote><div><br></div></div><div>We currently have ErrTerminateAgent, which signals that the agent should uninstall itself and then terminate. We probably just want an ErrRestartAgent which exits the process; upstart will restart it.</div>
<div><br></div></div></div></div></blockquote><div><br></div><div>I believe this is already what will happen now if a worker returns fatalError but creating a ErrRestartAgent and handling it appropriately would probably be cleaner. </div>
</div><br></div></div>