<div dir="ltr">Just found this on the juju list, did the juju-run command ever materialize? <div><br></div><div>Seems like it would be very valuable to be able to run arbritrary hooks rather than waiting for debug-hooks to intercept.<div>
<br></div><div>I've noticed debug-hooks doesn't seem to work for the install hook??</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 15, 2012 at 2:34 AM, Peter M. Petrakis <span dir="ltr"><<a href="mailto:peter.petrakis@canonical.com" target="_blank">peter.petrakis@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"><br>
<br>
On 11/14/2012 11:42 AM, Gustavo Niemeyer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Nov 14, 2012 at 2:36 PM, Peter M. Petrakis<br>
<<a href="mailto:peter.petrakis@canonical.com" target="_blank">peter.petrakis@canonical.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It would be neat if we could run debug-hooks directly on the host<br>
or just setup the entire environment on demand. This would also<br>
help with ancillary scripts that support complex charms. Currently<br>
I have to save away any envvars necessary at install time and<br>
echo | sed them into local scripts to maintain context.<br>
</blockquote>
<br>
We're actually on the way to have something very handy, but I'm not<br>
sure if it's exactly what you're looking for. We'll soon have a<br>
juju-run command that can be execute any script out-of-band, and have<br>
the full hook context so that the host can do whatever is needed even<br>
when no hooks are up.<br>
<br>
Would that help your use case?<br>
</blockquote>
<br></div>
Hmm, maybe. The use case is creating supporting scripts and include files<br>
that are used by other programs on the file system. Like an upstart job<br>
that calls functions included from a common include location. Currently<br>
I save away the charm home at install time and template this in. Alternatively<br>
I would have to create a space somewhere and copy said files to new location,<br>
and ensure they're overwritten during install/upgrade. Keeping them in the<br>
charm root ensures that they're unconditionally over written like the hook<br>
scripts themselves.<br>
<br>
See:<br>
<a href="http://bazaar.launchpad.net/~peter-petrakis/charms/precise/opengrok/trunk/files/head:/" target="_blank">http://bazaar.launchpad.net/~<u></u>peter-petrakis/charms/precise/<u></u>opengrok/trunk/files/head:/</a><br>

<br>
inc/common is leveraged by two additional scripts in scripts/ that are called from<br>
an upstart job I install.<br>
<br>
juju-run is neat, but it's still client side. I would also like the freedom to<br>
just fool around with the get/set agents outside of the debug-hooks context<br>
on the target e.g. to get a better feel for hacking new config.yaml keys. Currently,<br>
my only alternative is to intentionally create a broken hook and run debug-hooks<br>
from the discomfort of a screen'ish session.<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a><br>
<br>
</blockquote>
<br>
-- <br>
Juju mailing list<br>
<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/<u></u>mailman/listinfo/juju</a><br>
</div></div></blockquote></div><br></div>