Remove ContextAdapter from logging¶
We want to remove the
class as part of graduating
oslo.log, to reduce the API footprint.
ContextAdapter to add request context information to
log messages we output. Requiring a specially adapted logging handle
limits the scope of where that context information can be added, and
unnecessarily funnels all logging calls through the oslo logging
ContextHandlerimplements all of the same behaviors as
ContextAdapter, with respect to the values being output and their sources.
KeywordArgumentAdapaterto take named keyword arguments to logging methods and insert them into the ‘extra’ values for the log record (see below for details).
KeywordArgumentAdapterinstances instead of
The previous version of this spec suggested changing
to return a different adapter type with
deprecated() methods, allowing us to keep the API as it is for
now to buy time to update the callers that use the methods that would
otherwise be removed. Since we are starting this work at the beginning
of a cycle, I have updated the proposal to move us directly to the
sort of API we want to keep.
Impact on Existing APIs¶
We remove some APIs, but most of them have equivalent forms available from other libraries. There are three cases that do not.
ContextAdapter provides an
audit() method for
logging at INFO+1 level. This will be removed, and the log messages
updated to either use the INFO level or use the
with the audit level.
$ for d in ceilometer cinder glance heat ironic keystone neutron nova sahara trove swift;
do echo $d; ack LOG.audit $d/$d | wc -l; done
deprecated() method of the
replaced with a new function in
ContextAdapter keyword argument handling¶
ContextAdapter API supports doing:
LOG.info('some message: %(named_arg)s', named_arg=val, context=context)
The standard logger methods don’t accept arbitrary keyword arguments
to be part of the ‘extra’, but we have enough cases of this that we
need to continue to support the pattern to avoid churn and breaking
things in the other projects. We will implement a
KeywordArgumentAdapter to be returned by
Oslo libraries should not use this feature, to avoid circular dependencies between the libraries and oslo.log.
See “Impact on Existing APIs” above.
- Primary assignee:
Doug Hellmann (doug-hellmann)
- Other contributors:
- Target Milestone for completion:
Verify that the
ContextHandlerworks properly with
Message, and update it to make it work if it does not.
See “Proposed Change” above.
As apps that use the incubated version of oslo.log are updated, they
will need to be changed to get loggers directly from the standard
library module and to use
Anticipated API Stabilization¶
This change is part of stabilizing the API for oslo.log before graduation.
We need to remove the import cycle between log and versionutils before implementing this change. https://blueprints.launchpad.net/oslo/+spec/app-agnostic-logging-parameters
Discussion from the Juno summit: https://etherpad.openstack.org/p/juno-oslo-release-plan
Related blueprint on using our context as a base class: https://blueprints.launchpad.net/oslo.log/+spec/app-agnostic-logging-parameters
Related blueprint for graduating oslo.log: https://blueprints.launchpad.net/oslo.log/+spec/graduate-oslo-log
Related blueprint for fixing the import cycle between logging and versionutils: https://blueprints.launchpad.net/oslo-incubator/+spec/fix-import-cycle-log-and-versionutils
This work is licensed under a Creative Commons Attribution 3.0 Unported License. http://creativecommons.org/licenses/by/3.0/legalcode