Debug problem

David Cheney david.cheney at canonical.com
Fri Sep 6 00:49:45 UTC 2013


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



More information about the Juju mailing list