Debug problem

Kapil Thangavelu kapil.thangavelu at canonical.com
Fri Sep 6 14:44:46 UTC 2013


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
<david.britton at canonical.com>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 <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>
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130906/df0082b7/attachment.html>


More information about the Juju mailing list