Log configuration causes error in applications that have already processed configuration arguments
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
castellan |
Fix Released
|
Undecided
|
Fernando Diaz |
Bug Description
The module castellan.
Steps to reproduce:
1. create a simple application to demonstrate the error, this application follows a design pattern that is used for many OpenStack applications:
from oslo_config import cfg
from oslo_log import log
from castellan import key_manager
log.
cfg.CONF()
castellan_api = key_manager.API()
2. run the application
$ python log_error_test.py
Traceback (most recent call last):
File "log_error_
File "/home/
File "/home/
File "/home/
File "/home/
result = f(self, *args, **kwargs)
File "/home/
File "/home/
return f(self, *args, **kwargs)
File "/home/
raise ArgsAlreadyPars
oslo_
Recommended action.
This logging configuration should be re-assessed as it is being called everytime a user might acquire the API object for castellan. I don't think the library should be performing the action of configuring the log style or levels, these decisions should be left up to the application that consumes castellan.
I think the best possible option would be to provide this functionality as a configuration call that the user could make at an appropriate time in their application. There should also be documentation about how to increase the logging level for castellan.
description: | updated |
Changed in castellan: | |
assignee: | nobody → Fernando Diaz (diazjf) |
Fernando, another issue with the configure_logging function is that it should accept a ConfigOpt object instead of using the global oslo_config CONF object. The other configuration options have all been set to accept a user defined ConfigOpt and only use the global CONF is nothing is provided. This allows the consumer of castellan to be in full control of the configuration object that is used by their application.