[openstack-dev] [all] [oslo] Suggestion to change verbose=false to true in oslo.log by default

Dmitry Tantsur dtantsur at redhat.com
Mon Jul 27 10:32:39 UTC 2015


Hi all!

I didn't find the discussion on the ML so I feel like starting one.
What was the reason of setting verbose to false by default? The patch 
[1] does not provide any reasoning for it.

We all know that software does fail from time to time. While the default 
level of WARN might give some signal to an operator that *something* is 
wrong, it usually does not give much clues on *what* and *why*. Our logs 
guidelines define INFO as units of work, and the default means that 
operators/people debugging their logs won't even be able to track 
transitions in their system that lead to an error/warning.

Of all people I know 100% are using DEBUG level by default, the only 
post I've found here on this topic [2] seems to state the same. I 
realize that DEBUG might give too much information to process (though I 
always request people to enable debugging log before sending my any bug 
reports). But is there really a compelling reason to disable INFO?

Examples of INFO logs from ironic tempest run:
ironic cond: 
http://logs.openstack.org/62/202562/7/check/gate-tempest-dsvm-ironic-pxe_ssh/090871b/logs/screen-ir-cond.txt.gz?level=INFO
nova cpu: 
http://logs.openstack.org/62/202562/7/check/gate-tempest-dsvm-ironic-pxe_ssh/090871b/logs/screen-n-cpu.txt.gz?level=INFO
and the biggest one neutron agt: 
http://logs.openstack.org/62/202562/7/check/gate-tempest-dsvm-ironic-pxe_ssh/090871b/logs/screen-q-agt.txt.gz?level=INFO

As you can see, these logs are so small, you can just read through them 
without any tooling! Of course it's not a real world example, but I'm 
dealing with hundrer-of-megabytes debug-level text logs from nova + 
ironic nearly every day. It's still manangeable for me, grep handles it 
pretty well (to say nothing about journalctl).

WDYT about changing this default on oslo.log level?

Thanks,
Dmitry

[1] https://review.openstack.org/#/c/18110/
[2] 
http://lists.openstack.org/pipermail/openstack-operators/2014-March/004156.html



More information about the OpenStack-dev mailing list