Nova logs should be readable, sensible, and contain only errors and traces in exceptional situations
If Nova is acting normally, we shouldn't have stack traces in our logs. It will make problem determination by admins and developers unnessessarily hard as they'll have to mentally filter out important vs. "always happens" stack traces. We should enforce this by making gate fail if after we've running all the tests successfully we find stack traces in the logs.
We should also have consistent use of the info, audit, warn, and error levels, in a way that an opperator would actually know what's going on in a system. This means adjusting logging levels we use from other libraries to reduce distractions.
Blueprint information
- Status:
- Started
- Approver:
- Russell Bryant
- Priority:
- Low
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- Sean Dague
- Definition:
- Pending Approval
- Series goal:
- Accepted for trunk
- Implementation:
-
Slow progress
- Milestone target:
- None
- Started by
- Russell Bryant
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
translate cinder BadRequest exception
Addressed by: https:/
translate cinder BadRequest exception
Gerrit topic: https:/
Addressed by: https:/
Translate cinder NotFound exception
Gerrit topic: https:/
Addressed by: https:/
Translate NoMoreFloatingIps exception
Gerrit topic: https:/
Addressed by: https:/
remove duplicate ec2 request logging
Unapproved - please re-submit via nova-spec --johnthetubagy (20th March 2014)
Approving this, there is no milestone, but this is ongoing I guess. Ideally please add a milestone when you hope to complete these --johnthetubaguy (9th April 2014)
Feature Proposal Freeze means this must not land in juno, because it appears like the code is not all currently ready to be reviewed. To be able to merge in kilo, we would first need to merge a kilo spec. More details on the exact process will be available on the ML shortly. --johnthetubaguy 22nd August 2014
