Open Stack

Excerpts from Alexis Lee's message of 2016-05-25 16:24:59 +0100:
> Doug Hellmann said on Wed, May 25, 2016 at 11:06:35AM -0400:
> > Excerpts from Alexis Lee's message of 2016-05-25 13:46:05 +0100:
> > >   def some_method(ctx):
> > >       log = tools.get_api_logger(ctx) or LOG
> > 
> > That "or" statement in some_method() seems to imply though that
> > when spool logging is on, messages would *only* go through the
> > spooling logger. Is that what we want? Even for info messages?
> 
> The global logger (LOG) is still accessible so if you definitely want a
> message in the main log, you can use that instead. I'll use "reqlog"
> instead of "log" in future to make the two more quickly distinguishable.
> EG a "warning, disk running out of space" may be discovered during
> request processing but isn't tied to that request, so it makes more
> sense to send that to the main log.
> 
> If we want a message to go to both loggers, without going to the global
> logger twice, we can do:
> 
>     if reqlog != LOG:
>         reqlog.info("...")
>     LOG.info("...")

But that leaves it up to the application or library author to have to
make that call for every log message, which makes logging more
complicated.

The point of the spooling logger is to dump everything about a request
when the request fails, right? And we want the "normal" behavior the
rest of the time? It seems like we should look at a way to make that
happen without a lot of impact on application logic.

It's OK to have the same message go to both loggers, right? Could we
have a wrapper class that takes a normal logger and a spooling logger
and sends its messages to both?

So you might do something like:

  reqlog = tools.get_request_logger('api', context, LOG)

And if the spool_api option is off, you get back the LOG object and if
it's on you get back a SpoolLoggerWrapper or something that duplicates
the message to the actual spool logger and to LOG.

  reqlog.info('this message goes both places')
  reqlog.debug('this is only emitted by the spool logger')

Even better would be to find a way to configure the logger hierarchy
so that is completely transparent, so that messages going to the
SpoolLogger are propagated to the normal logger based on their log
level. That would mean rearranging the planned hierarchy, I think, to
avoid having to connect two separate parts of the tree like the
SpoolLoggerWrapper proposed above does.

Doug

> 
> 
> Alexis (lxsli)