Debug problem

Fri Sep 6 14:39:05 UTC 2013

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 <marco at ondina.co> 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 <
> mark.ramm-christensen at canonical.com> 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 <david.cheney at canonical.com>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
>>> <gustavo.niemeyer at canonical.com> 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 <matt.rae at canonical.com>
>>> 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
>>> >> <peter.petrakis at canonical.com> wrote:
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 11/14/2012 11:42 AM, Gustavo Niemeyer wrote:
>>> >>>>
>>> >>>> On Wed, Nov 14, 2012 at 2:36 PM, Peter M. Petrakis
>>> >>>> <peter.petrakis at canonical.com> 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
>>> >>> Juju at lists.ubuntu.com
>>> >>> Modify settings or unsubscribe at:
>>> >>> https://lists.ubuntu.com/mailman/listinfo/juju
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > gustavo @ http://niemeyer.net
>>> >
>>> > --
>>> > Juju mailing list
>>> > Juju at lists.ubuntu.com
>>> > Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>> --
>>> Juju mailing list
>>> Juju at lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>

-- 
David Britton <david.britton at canonical.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130906/b0f245c3/attachment-0001.html>