A --wait-for-debug flag would be nice. Something I've been doing during charm schools and for local charm development is sticking an exit 1 at the top of the install hook. This puts the charm in an error state and allows you to then run debug-hooks, resolved --retry the unit, then remove the exit 1 and continue on with the install hook.
On Fri, Sep 6, 2013 at 6:56 AM, Mark Canonical Ramm-Christensen < [email protected]> wrote: > 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. > > --Mark Ramm > > > On Fri, Sep 6, 2013 at 1:49 AM, David Cheney > <[email protected]>wrote: > >> 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 >> > > > -- > 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
