<div dir="ltr">The only solution I can think of is to either: add a wait at the beginning of the install hook, so you have time to get in, or possibly we could pass the need to run debug hooks into the deploy command. Perhaps this could be a flag like --delay-hook-executions or just --wait-for-debug, so that the agent knows not to run install until an debug-hooks connection is active. <div> </div><div>--Mark Ramm</div></div><div class="gmail_extra"> <div class="gmail_quote">On Fri, Sep 6, 2013 at 1:49 AM, David Cheney <<a href="mailto:david.cheney@canonical.com" target="_blank">david.cheney@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In theory you should be able to debug the install hook, but the timing is quite tricky. You won't be able to execute the debug-hooks command until the unit has been written into the state, and then you are racing with the install hook starting. I tried a few times and wasn't able to catch it at just the right point, even with a machine pre deployed via add-machine. <div class="HOEnZb"><div class="h5"> On Fri, Sep 6, 2013 at 3:25 AM, Gustavo Niemeyer <<a href="mailto:gustavo.niemeyer@canonical.com">gustavo.niemeyer@canonical.com</a>> wrote: > Regarding juju-run, not that I'm aware of, but it's at least a great > feature that I'm sure is still somewhere in the TODO list. > > As for the debug-hooks omission of the install hook, that would be a bug. > > > On Thu, Sep 5, 2013 at 6:04 AM, Matt Rae <<a href="mailto:matt.rae@canonical.com">matt.rae@canonical.com</a>> wrote: >> Just found this on the juju list, did the juju-run command ever materialize? >> >> Seems like it would be very valuable to be able to run arbritrary hooks >> rather than waiting for debug-hooks to intercept. >> >> I've noticed debug-hooks doesn't seem to work for the install hook?? >> >> >> On Thu, Nov 15, 2012 at 2:34 AM, Peter M. Petrakis >> <<a href="mailto:peter.petrakis@canonical.com">peter.petrakis@canonical.com</a>> wrote: >>> >>> >>> >>> On 11/14/2012 11:42 AM, Gustavo Niemeyer wrote: >>>> >>>> On Wed, Nov 14, 2012 at 2:36 PM, Peter M. Petrakis >>>> <<a href="mailto:peter.petrakis@canonical.com">peter.petrakis@canonical.com</a>> wrote: >>>>> >>>>> It would be neat if we could run debug-hooks directly on the host >>>>> or just setup the entire environment on demand. This would also >>>>> help with ancillary scripts that support complex charms. Currently >>>>> I have to save away any envvars necessary at install time and >>>>> echo | sed them into local scripts to maintain context. >>>> >>>> >>>> We're actually on the way to have something very handy, but I'm not >>>> sure if it's exactly what you're looking for. We'll soon have a >>>> juju-run command that can be execute any script out-of-band, and have >>>> the full hook context so that the host can do whatever is needed even >>>> when no hooks are up. >>>> >>>> Would that help your use case? >>> >>> >>> Hmm, maybe. The use case is creating supporting scripts and include files >>> that are used by other programs on the file system. Like an upstart job >>> that calls functions included from a common include location. Currently >>> I save away the charm home at install time and template this in. >>> Alternatively >>> I would have to create a space somewhere and copy said files to new >>> location, >>> and ensure they're overwritten during install/upgrade. Keeping them in the >>> charm root ensures that they're unconditionally over written like the hook >>> scripts themselves. >>> >>> See: >>> >>> <a href="http://bazaar.launchpad.net/~peter-petrakis/charms/precise/opengrok/trunk/files/head:/" target="_blank">http://bazaar.launchpad.net/~peter-petrakis/charms/precise/opengrok/trunk/files/head:/</a> >>> >>> inc/common is leveraged by two additional scripts in scripts/ that are >>> called from >>> an upstart job I install. >>> >>> juju-run is neat, but it's still client side. I would also like the >>> freedom to >>> just fool around with the get/set agents outside of the debug-hooks >>> context >>> on the target e.g. to get a better feel for hacking new config.yaml keys. >>> Currently, >>> my only alternative is to intentionally create a broken hook and run >>> debug-hooks >>> from the discomfort of a screen'ish session. >>> >>> >>>> >>>> >>>> gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a> >>>> >>> >>> -- >>> Juju mailing list >>> <a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a> >>> Modify settings or unsubscribe at: >>> <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a> >> >> > > > > -- > gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a> > > -- > Juju mailing list > <a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a> > Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a> -- Juju mailing list <a href="mailto:Juju@lists.ubuntu.com">Juju@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/juju" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a> </div></div></blockquote></div> </div>