Debug problem

Marco Ceppi marco at ondina.co
Fri Sep 6 12:32:26 UTC 2013


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130906/36b6bdb5/attachment.html>


More information about the Juju mailing list