<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 4, 2013 at 10:40 AM, Tom Haddon <span dir="ltr"><<a href="mailto:tom.haddon@canonical.com" target="_blank">tom.haddon@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 class="im">On 04/04/13 15:27, Kapil Thangavelu wrote:<br>
><br>
> fwiw in the python version this goes..<br>
><br>
> If you want to distribute the new charm to the units, the following will<br>
> put the new charm in place regardless of current unit error state. It<br>
> this just drops the new charm on to disk.  it does not run upgrade-charm<br>
> hook with the --force flag.<br>
><br>
> $ juju upgrade-charm --force service<br>
><br>
> Even without the upgrade you have two options, either a) retry the<br>
> failed op with the new hook, specifying relation name if its a relation<br>
> error and you want the relation hook to re-executed. The execution<br>
> environment is the same as the original execution environment in terms<br>
> of the units seen  of the remote side, although current relation<br>
> settings for those may have changed from the original execution env.<br>
><br>
> $ juju resolved --retry unit_name [relation_name]<br>
><br>
> Alternatively manually mark the error as resolved, typically as a result<br>
> of manual intervention.<br>
><br>
>  $ juju resolved  unit_name [relation_name]<br>
<br>
</div>The particular case here is that we don't actually have a relation<br>
error, we just want to change the implementation of the hook. Can you<br>
run "juju resolved --retry unit_name [relation_name]" even if there's no<br>
error?<br></blockquote><div><br></div><div style>Resolved --retry against a unit in a good state is no-op.</div><div><br></div><div style>The underlying capability to run a hook out of band of orchestration, has been ruminated on a few times but it doesn't exist. Its effectively a juju-cli api form of juju-run-hook whereby an adminstrator or cron job can run a hook. Its an important conceptual piece as well as it allows external feedback into juju. The closest thing we have is a jitsu tool to run-as-hook but its broken by design imo, in that its runs something on the client with the hook environment which is not what users generally expect.</div>
<div> </div><div><br></div><div style>cheers,</div><div style><br>Kapil</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> On Thu, Apr 4, 2013 at 10:07 AM, Tom Haddon <<a href="mailto:tom.haddon@canonical.com">tom.haddon@canonical.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:tom.haddon@canonical.com">tom.haddon@canonical.com</a>>> wrote:<br>
><br>
>     Hi Folks,<br>
><br>
>     If we have a problem with a particular hook, and fix that, we can<br>
>     upgrade-charm to rollout the fixed version of the charm. However, how do<br>
>     we actually fire the hook in question? I'm looking for this in terms of<br>
>     the "right way"™ as there are a few manual ways of doing this I can<br>
>     think of. Should we include the hook we want to run in the upgrade-charm<br>
>     hook? If the hook is a relation-changed, we don't necessarily want to do<br>
>     anything invasive to trigger that hook from being fired (such as<br>
>     changing the environment) we just want the hook to be rerun.<br>
><br>
>     Thanks, Tom<br>
><br>
>     --<br>
>     Juju mailing list<br>
</div>>     <a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a> <mailto:<a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a>><br>
<div class="HOEnZb"><div class="h5">>     Modify settings or unsubscribe at:<br>
>     <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>