Debug-Log CLI / API Changes

[roger peppe]

On 18 February 2014 17:48, William Reade <william.reade at canonical.com> wrote:
> I'd prefer to drop --include entirely, and make positional args automatic
> includes; and never to mention "environment" at the CLI level; but that then
> makes it hard to distinguish between an entity name and a regex to apply to
> the whole environment... *unless* we add a --filter arg for that specific
> case. Does that work, or do we still have ambiguity lurking? There might be
> an issue with regexes containing "="...

If we say that a regex is *always* preceded by a "=" (actually I prefer ":"
but I don't want to bikeshed too much), then there's no ambiguity - we
can allow an empty entity name to imply "environment". We need to do
this, because otherwise there's an ambiguity between a service named
"environment" and the environment tag.

The other thing I'd suggest is that regexes apply to the text
following the tag (you can't use a regex to filter the tag) - this makes an
efficient implementation easier, and largely avoids the implementation
leakage that Kapil refers to, I believe.

I agree with William that we can leave out the explicit --include
flags.

So:

    juju debug-log =somepattern

would be (almost) equivalent to:

    juju debug-log | grep somepattern

(it would actually be equivalent to "juju debug-log | grep ':.*somepattern'"
because the pattern wouldn't match the tags at the start of the line).

   juju debug-log wordpress=HOOK

would select any lines produced by the wordpress service that
contain the word HOOK.

For the record, here's some code which implements the server
side matching algorithm according to the above specification:
http://play.golang.org/p/Zm-RSBoR6v