Re: Call for help for a juju plugin
On Wed, Mar 4, 2015 at 10:12 AM, Adam Collard adam.coll...@canonical.com wrote: Why not stick to the UNIX principle and compose a pipeline? That would also do the trick, as long as it's something that can capture what's going on in one snippet. -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Call for help for a juju plugin
On 4 March 2015 at 13:45, Jorge O. Castro jo...@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 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Call for help for a juju plugin
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. Marco and I thought something like `juju pastebinit` would be a good idea. Just give me a dump of all the logs on the units so I can send that to the bundle/charm author. https://github.com/juju/plugins/issues/52 The eco team is gearing up for a sprint so our pattern is kind of full, so I'd thought I'd send this out to the list to see if anyone is looking for a quick plugin to bust out that would help people out in the field debug their problems faster. -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Call for help for a juju plugin
Why not stick to the UNIX principle and compose a pipeline? With https://bugs.launchpad.net/juju-core/+bug/1390585 fixed it could be as simple as juju debug-log --no-stream --replay | pastebinit On 4 March 2015 at 13:45, Jorge O. Castro jo...@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. Marco and I thought something like `juju pastebinit` would be a good idea. Just give me a dump of all the logs on the units so I can send that to the bundle/charm author. https://github.com/juju/plugins/issues/52 The eco team is gearing up for a sprint so our pattern is kind of full, so I'd thought I'd send this out to the list to see if anyone is looking for a quick plugin to bust out that would help people out in the field debug their problems faster. -- Jorge Castro Canonical Ltd. http://juju.ubuntu.com/ - Automate your Cloud Infrastructure -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
