On Fri, May 31, 2013 at 12:47 PM, Tim Penhey <email address hidden>wrote:
> The proposal to merge lp:~thumper/juju-core/use-loggo into lp:juju-core
> has been updated.
>
> Description changed to:
>
> Integrate loggo as a hierarchical logger.
>
> The existing logging is very flat and has very little control over what is
> output.
>
> I wrote loggo as a Go port of a C++ library I wrote for nux/unity (my
> third or fourth logging library). Loggers are very lightweight objects
> that have a single pointer to the module. A module is defined by a dotted
> name, like "juju.uniter" or "juju.provider.ec2". There is no limit to the
> depth of nesting. Logging levels are inherited unless explicitly set. The
> root logger, identified by the module "" (empty string), defaults to
> WARNING.
>
> The existing log package has been updated to use the loggo methods so we
> don't have to change all the call sites immediately. However we should
> start to move to more detailed modules for logging as we can have better
> control over it.
>
> We should, as a soon to be done step, provide a way, probably using
> set-env, to configure logging for various machine agents or unit agents.
> This would allow a high level of control over what information gets logged.
>
> https://codereview.appspot.com/9738051/
>
> For more details, see:
> https://code.launchpad.net/~thumper/juju-core/use-loggo/+merge/166611
> --
> https://code.launchpad.net/~thumper/juju-core/use-loggo/+merge/166611
> Your team juju hackers is requested to review the proposed merge of
> lp:~thumper/juju-core/use-loggo into lp:juju-core.
>
LGTM.
On Fri, May 31, 2013 at 12:47 PM, Tim Penhey <email address hidden>wrote:
> The proposal to merge lp:~thumper/juju-core/use-loggo into lp:juju-core ec2". There is no limit to the /codereview. appspot. com/9738051/ /code.launchpad .net/~thumper/ juju-core/ use-loggo/ +merge/ 166611 /code.launchpad .net/~thumper/ juju-core/ use-loggo/ +merge/ 166611
> has been updated.
>
> Description changed to:
>
> Integrate loggo as a hierarchical logger.
>
> The existing logging is very flat and has very little control over what is
> output.
>
> I wrote loggo as a Go port of a C++ library I wrote for nux/unity (my
> third or fourth logging library). Loggers are very lightweight objects
> that have a single pointer to the module. A module is defined by a dotted
> name, like "juju.uniter" or "juju.provider.
> depth of nesting. Logging levels are inherited unless explicitly set. The
> root logger, identified by the module "" (empty string), defaults to
> WARNING.
>
> The existing log package has been updated to use the loggo methods so we
> don't have to change all the call sites immediately. However we should
> start to move to more detailed modules for logging as we can have better
> control over it.
>
> We should, as a soon to be done step, provide a way, probably using
> set-env, to configure logging for various machine agents or unit agents.
> This would allow a high level of control over what information gets logged.
>
> https:/
>
> For more details, see:
> https:/
> --
> https:/
> Your team juju hackers is requested to review the proposed merge of
> lp:~thumper/juju-core/use-loggo into lp:juju-core.
>