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.
On Fri, Sep 6, 2013 at 3:25 AM, Gustavo Niemeyer <[email protected]> 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 <[email protected]> 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 >> <[email protected]> wrote: >>> >>> >>> >>> On 11/14/2012 11:42 AM, Gustavo Niemeyer wrote: >>>> >>>> On Wed, Nov 14, 2012 at 2:36 PM, Peter M. Petrakis >>>> <[email protected]> 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: >>> >>> http://bazaar.launchpad.net/~peter-petrakis/charms/precise/opengrok/trunk/files/head:/ >>> >>> 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 @ http://niemeyer.net >>>> >>> >>> -- >>> Juju mailing list >>> [email protected] >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >> >> > > > > -- > gustavo @ http://niemeyer.net > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
