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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev