Debug problem

Mark Canonical Ramm-Christensen mark.ramm-christensen at canonical.com
Fri Sep 6 10:56:18 UTC 2013


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


More information about the Juju mailing list