On Wed, Feb 19, 2014 at 9:50 AM, Dimiter Naydenov < [email protected]> 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 <[email protected]> > To: Dimiter Naydenov <[email protected]> > > On 18 February 2014 23:01, Dimiter Naydenov > <[email protected]> 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
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
