Logging changes coming with juju 1.15

[David Cheney]

I take blame for the 'primitive log system', this was my idea. But in
my defense, debug-log wasn't even on the table 6 weeks before 13.04
and the 'shove it all through syslog' was accepted as a solution that
would get _a_ debug-log in the hands of users.

Should it be replaced ? Absolutely, but please keep in mind it was
born of pragmatism, not incompetence.

On Fri, Sep 27, 2013 at 8:46 AM, Kapil Thangavelu
<kapil.thangavelu at canonical.com> wrote:
> Re different channels for user, perhaps.. at the moment its unclear in some
> cases where one begins and one ends. Some of the information that a user
> wants to see is currently tied up in framework. ie. events around execution
> of potentially non existant hooks (config-changed would have been called,
> start, rel-joined, etc). The ability to filter gives the user the option to
> find what they care about in any given context.
>
> Re filtering also the ability to filter specifically to specific units is
> critical, in terms of finding a specific error, else you end up grepping the
> whole class (with -n to pull history). the context of the current log level
> & channel lacks identity outside of machine ip.. ideally we'd see things
> like machine id:1  and unit_id which would also be filterable items.
>
> fwiw as context to a filtering impl, previous debug-log help was
>
> usage: juju debug-log [-h] [-e ENVIRONMENT] [-r] [-i INCLUDE] [-x EXCLUDE]
>                       [-l {DEBUG,INFO,WARNING,ERROR,CRITICAL}] [-n LIMIT]
>                       [-o OUTPUT]
>
> Enables a distributed log for all agents in the environment, and displays
> all
> log entries that have not been seen yet.
>
> optional arguments:
>   -h, --help            show this help message and exit
>   -e ENVIRONMENT, --environment ENVIRONMENT
>                         juju environment to operate in.
>   -r, --replay          Display all existing logs first.
>   -i INCLUDE, --include INCLUDE
>                         Filter log messages to only show these log channels
> or
>                         agents/units. Multiple values can be specified, also
> supports
>                         unix globbing.
>   -x EXCLUDE, --exclude EXCLUDE
>                         Filter log messages to exclude these log channels or
>                         agents/units. Multiple values can be specified, also
> supports
>                         unix globbing.
>   -l {DEBUG,INFO,WARNING,ERROR,CRITICAL}, --level
> {DEBUG,INFO,WARNING,ERROR,CRITICAL}
>                         Log level to show
>   -n LIMIT, --limit LIMIT
>                         Show n log messages and exit.
>   -o OUTPUT, --output OUTPUT
>                         File to log to, defaults to stdout
>
>
>
> On Thu, Sep 26, 2013 at 6:40 PM, Tim Penhey <tim.penhey at canonical.com>
> wrote:
>>
>> On 27/09/13 10:26, Kapil Thangavelu wrote:
>> > I don't think the log collection is the issue though this is still
>> > useful to help mitigate perhaps some of the log accumulation on disk
>> > (despite rotation archival). The problem is the primitive log display
>> > which amounts to tail aggregated syslog. As an end user, i don't care
>> > about framework internals, i care about seeing the provider mutations
>> > (create, destroy, sec group maybe), hook execution, and errors. With
>> > juju-core there isn't any ability to filter the log from the client on a
>> > given channel/hierarchy or level, and currently any usage of log
>> > basically fills up with ping api traffic obscuring actual content.
>>
>> I agree entirely.  Although I feel that this is a step in the right
>> direction.
>>
>> What we could do, and I was thinking about this after I wrote the last,
>> is to have the hook logs, and the hook log command, go through a
>> particular module, and make sure that is always logged out.
>>
>> Ideally I want a different channel of information for user information,
>> as opposed to developer information.  This is still work in thought (not
>> even progress yet).
>>
>> Tim
>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>