Pyjuju used state to represent debug-hooks. The unit state exists as soon as add-unit/deploy is done, and then pyjuju could attach the debug flag to the unit state. The unit agent (and its machine) would come up and observe/act upon its state, and process debug-hooks before entering into its state machine. With juju-core there is no use of state for debug hooks, and no coordination around the unit's statemachine, its a soley a race of the existence of the tmux session before a hook executes. It does seem like a bug.
cheers, Kapil On Fri, Sep 6, 2013 at 10:39 AM, David Britton <[email protected]>wrote: > BTW, pyjuju had some problems like this as well, however, it had some > ability to wait till the environment came up if was in the process of > spinning up still. allowing you to reliably do: > > juju deploy foo; juju debug-hook foo/N # where N was the next unit > number in sequence > > I guess pyjuju worked a bit different with sequencing commands, but I > don't quite understand this part yet. > > > On Fri, Sep 6, 2013 at 6:32 AM, Marco Ceppi <[email protected]> wrote: > >> 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 >> >> > > > -- > David Britton <[email protected]> > > -- > 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
