Open Stack

Excerpts from Sean Dague's message of 2016-05-24 14:16:13 -0400:
> On 05/24/2016 01:18 PM, Doug Hellmann wrote:
> > Excerpts from Alexis Lee's message of 2016-05-24 09:34:36 +0100:
> >> Hi,
> >>
> >> I have a spec: https://review.openstack.org/227766
> >> and implementation: https://review.openstack.org/316162
> >> for adding a spooling logger to oslo.log. Neither is merged yet, reviews
> >> welcome.
> >>
> >> Looking at how I'd actually integrate this into Nova, most classes do:
> >>
> >>     LOG = logging.getLogger(__name__)
> >>
> >> which is the recommended means of getting a logger. I need to get
> >> certain code paths to use a different logger (if spooling is turned on).
> >> This means I need to pass it around. If I modify method signatures I'm
> >> bound to break back-compat for something.
> >>
> >> Option 1: use a metaclass to register each SpoolManager as a singleton,
> >> IE every call to SpoolManager('api') will return the same manager. I can
> >> then do something like:
> >>
> >>     log = LOG
> >>     if CONF.spool_api:
> >>         log = SpoolManager('api').get_spool(context.request_id)
> >>
> >> in every method.
> >>
> >> Option 2: Put the logger on the context. We're already passing this
> >> everywhere so it'd be awful convenient.
> >>
> >>     log = context.log or LOG
> >>
> >> Option 3: ???
> >>
> >> I like option 2, any objections to extending oslo.context like this?
> >>
> >>
> >> Alexis (lxsli)
> > 
> > Do you need more than one? The spec talks about different types of
> > requests having different SpoolManagers (api and scheduler are the 2
> > examples given).
> > 
> > What happens when the context is serialized and sent across an RPC call?
> > Is there some representation of the logger that the messaging code can
> > use on the other side to reconstruct the logger?
> 
> Right, the serialization of the context makes this something I'd rather
> avoid. While in the past I've argued for adding more to context, it is
> sort of useful that it's mostly just a container of attributes for being
> a universal thing. Doug corrected my thinking there, and I thank him for
> it.
> 
> I'd rather have it be more explicit.
> 
>     -Sean
> 

Rather than forcing SpoolManager to be a singleton, maybe the thing
to do is build some functions for managing a singleton instance (or
one per type or whatever), and making that API convenient enough
that using the spool logger doesn't require adding a bunch of logic
and import_opt() calls all over the place.  Since it looks like the
convenience function would require looking at a config option owned
by the application, it probably shouldn't live in oslo.log, but
putting it in a utility module in nova might make sense.

Doug