Nova logs should be readable, sensible, and contain only errors and traces in exceptional situations

Registered by Sean Dague on 2013-03-21

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

Russell Bryant
Needs approval
Sean Dague
Pending Approval
Series goal:
Accepted for trunk
Slow progress
Milestone target:
Started by
Russell Bryant on 2013-03-22

Related branches



Gerrit topic:,topic:bug/1158505,n,z

Addressed by:
    translate cinder BadRequest exception

Addressed by:
    translate cinder BadRequest exception

Gerrit topic:,topic:bug/1169777,n,z

Addressed by:
    Translate cinder NotFound exception

Gerrit topic:,topic:bug/1169811,n,z

Addressed by:
    Translate NoMoreFloatingIps exception

Gerrit topic:,topic:bp/clean-logs,n,z

Addressed by:
    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


Work Items

This blueprint contains Public information 
Everyone can see this information.