Debug-Log CLI / API Changes

[William Reade]

On Wed, Feb 19, 2014 at 9:50 AM, Dimiter Naydenov <
dimiter.naydenov at canonical.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Fwd to juju-dev. Having --level is a good suggestion, I like it.
>
> - -------- Original Message --------
> Subject: Re: Debug-Log CLI / API Changes
> Date: Wed, 19 Feb 2014 15:41:42 +0700
> From: Stuart Bishop <stuart.bishop at canonical.com>
> To: Dimiter Naydenov <dimiter.naydenov at canonical.com>
>
> On 18 February 2014 23:01, Dimiter Naydenov
> <dimiter.naydenov at canonical.com> wrote:
>
> > The API for debug-log will support internally a list of pairs
> > name-regexp and an exclude flag. Only the name part is required.
> > In CLI terms, we're proposing to express this as:
> >
> > juju debug-log name1[=regexp1] name2[=regexp2] ... --exclude
> > name3[=regexp3] --exclude name4[=regexp4] ...
> >
> > Which is equivalent to the more explicit:
> >
> > juju debug-log --include name1[=regexp1] --include name2[=regexp2]
> > ... - --exclude name3[=regexp3] --exclude name4[=regexp4] ...
> >
> > The full syntax for --include and --exclude is
> > --include=name=regexp, where both the first "=" and the "=regexp"
> > parts are optional. If no - --include arguments are specified, they
> > are assumed.
> >
> > Examples: juju debug-log --include
> > wordpress/0='.*config-changed.*'
>
> Filtering by regexp can be done easily enough with grep. I'm more
> interested it the juju debug-log filters being able to decode the
> stream and separate out messages from services, units, hooks, juju
> internals from the firehose. So 'juju debug-log --include foo/0' would
> reliably spit out the messages from foo/0. The scope would be unit,
> service or whole-environment.
>
> If I want to filter this, I'd be wanting to separate out:
>   - All hook output (juju-log'd & stdout/stderr).
>   - Hook output and LOGLEVEL or above (hook output without a log level
> would be equivalent to DEBUG, or something like that).
>   - Hooks fired, Hooks queued to run, Hook result (I'd have all of
> these or none of these, rather than 3 separate toggles)
>   - relation-set details
>

+1 on level. I don't want to gate landing this on message-kind filtering,
but I'm generally +1 on the idea; I'd quite like tim's input before we
settle on an implementation. Happy to discuss what message kinds we'd need
in more detail here though:

* hook stdout/stderr seems definitely useful, no objections there
* the hook queue is dynamic and unit-local and I currently have no
intention of exposing it to the state server, let alone the user... what's
the  use case for it?
* hook firing/result pretty much subsumes relation-set info, I don't think
it's a good idea to make it easy to see relation-sets as they happen; I'm
fine communicating the aggregate effect of all relation-sets once the hook
has completed and the changes are sent to the state server, though

It seems that we can probably cover this with "hook-info" and "hook-output"
message kinds. But... is there ever a case where you want output but don't
need to know what hooks are running? It STM that if you ever want
hook-output you also always want hook-info, and that the effect of the
relation-sets is a DEBUG-level detail of the hook-info messages.

Cheers
William
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140219/528bf86c/attachment.html>