Debug problem

Gustavo Niemeyer gustavo.niemeyer at canonical.com
Thu Sep 5 17:25:32 UTC 2013


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



More information about the Juju mailing list