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 <[email protected]> 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 > <[email protected]> wrote: >> >> >> >> On 11/14/2012 11:42 AM, Gustavo Niemeyer wrote: >>> >>> On Wed, Nov 14, 2012 at 2:36 PM, Peter M. Petrakis >>> <[email protected]> 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 >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju > > -- gustavo @ http://niemeyer.net -- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
