Define what goes into info or debug for Logging
Currently we have LOG.info and LOG.debug inconsistently. We need to
(1) Define what information makes sense to go into info and what goes into debug
(2) Have a consistent format in logging
(3) Ensure that the information in the logs is reasonably good and provides some useful information in tracking issues.
Blueprint information
- Status:
- Started
- Approver:
- None
- Priority:
- Low
- Drafter:
- Vinod Mangalpally
- Direction:
- Needs approval
- Assignee:
- Vinod Mangalpally
- Definition:
- Approved
- Series goal:
- None
- Implementation:
- Good progress
- Milestone target:
- None
- Started by
- Tim Simmons
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Totally agree, at HP we run with debug logging enabled.. Without that, the logging simply in not complete enough (kiall).
As it stands now, the collection of log statements in Designate is somewhat comprehensive, but can be improved. There are multiple requests for the current statements to be modified to be more consistent with Openstack logging standards. In addition, many contributors find that when debug mode is disabled, the logging is too sparse to be useful.
This task will most likely consist of several passes through Designate's existing log statements and code base in general. The first pass will be made to modify the log levels and message translation markers to better conform to Openstack logging and translation/I18n standards, respectively (particularly the ones at this link: https:/
Gerrit topic: https:/
Addressed by: https:/
Change log statements to meet I18n guidelines
Addressed by: https:/
WIP: Update hacking package, fix I18n style issues
Gerrit topic: https:/
Addressed by: https:/
Change log string format to '%' for consistency
Addressed by: https:/
WIP: Strawman logging clean up
Work Items
Dependency tree
* Blueprints in grey have been implemented.