Debug problem

[Peter M. Petrakis]

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
>