Call for help for a juju plugin

[Simon Davy]

On 4 March 2015 at 13:45, Jorge O. Castro <jorge at ubuntu.com> wrote:
> Hi everyone,
>
> Sometimes people deploy things like a complex bundle on a cloud and it
> doesn't work. Having to wrangle the person to find out which units
> broke, juju sshing in and manually digging around logs and refiring
> off hooks, etc. is time consuming.

This is a great idea, and should be doable for shipping just juju
logs/config, and possibly relation data.

But if you'd want to include logs/config for the service, I think
you'd need a way for charms to expose there logs (path[1], type) and
configs somehow. This could maybe be part of the charm metadata, but
paths are not necessarily fixed locations, as config can affect
them[1]. So maybe a charm could publish this information in the juju
status output, as part of service metadata? I think there was some
discussion of custom status output at some point.

This would be useful for the above scenario[2], but also in
development of full stacks, and debugging in production. Some useful
tools/plugins that this would enable:

juju-tail-logs <unit> could use multitail to tail all logs on that
unit simultaneously, as I send a test request to the unit and watch
what happens. Bonus for a --filter <regex> argument :)

juju-log-trace <access|error> could multitail all access|error on all
units that publish them, so I can trace http requests coming though
mutliple units of apache->haproxy->squid->haproxy->app servers (I do
this manually sometimes now, but it's a pain, and I must know the
location of every log file for each unit). Ditto for the --filter
argument.

juju-view-configs could open all the config files in a stack for
viewing in $EDITOR, vastly simplify checking if the desired
relations/config have produced the correct result you were looking
for. I regularly do this manually, one by one, with stuff like juju
ssh <unit> 'cat /etc/haproxy/haproxy.cfg', for example.

Another use case would be to surface the logs and config in the GUI,
which IMO would be a killer feature for GUI adoption in production
environments.

In fact, this simple change could expose a whole raft of system
diagnosis tooling that would be real value-add to the base juju
proposition, IMO.

HTH

[1] As recommended in our current best practice docs:
https://jujucharms.com/docs/authors-charm-best-practice (Disclaimer: I
am not convinced by all of those guidelines)

[2] There's an issue here with sensitive information, like PID and
secrets. I think the pastebinit plugin would need to be able to dump
locally, to allow redaction prior to submitting, if it was every going
to be able to be used in production systems. Some data (IPs, emails,
etc) could be auto-redacted in the tool, perhaps.


-- 
Simon