On 09/26/2014 12:03 AM, Christopher Yeoh wrote:
On Thu, 25 Sep 2014 08:49:12 -0400
Sean Dague s...@dague.net wrote:
#1 - tried to get a lock, but someone else has it. Then we know we've
got lock contention. .
#2 - something is still holding a lock after some long amount of
time.
+1 to
On 09/25/2014 03:06 PM, Ben Nemec wrote:
On 09/25/2014 07:49 AM, Sean Dague wrote:
Spending a ton of time reading logs, oslo locking ends up basically
creating a ton of output at DEBUG that you have to mentally filter to
find problems:
2014-09-24 18:44:49.240 DEBUG
+1 for making those two changes. I also have been frustrated doing
debugging in the gate recently, and any operational-ease-of-debugging
things like this would be appreciated.
-jay
On 09/25/2014 08:49 AM, Sean Dague wrote:
Spending a ton of time reading logs, oslo locking ends up basically
Logged as high priority bug -
https://bugs.launchpad.net/oslo.concurrency/+bug/1374075
On Thu, Sep 25, 2014 at 1:57 PM, Jay Pipes jaypi...@gmail.com wrote:
+1 for making those two changes. I also have been frustrated doing debugging
in the gate recently, and any operational-ease-of-debugging
On 09/25/2014 07:49 AM, Sean Dague wrote:
Spending a ton of time reading logs, oslo locking ends up basically
creating a ton of output at DEBUG that you have to mentally filter to
find problems:
2014-09-24 18:44:49.240 DEBUG nova.openstack.common.lockutils
Or how about we add in a new log level?
A few libraries I have come across support the log level 5 (which is less than
debug (10) but greater than notset (0))...
One usage of this is in the multiprocessing library in python itself @
...@nemebean.com; OpenStack Development Mailing List (not for usage
questions)
Subject: Re: [openstack-dev] [oslo] logging around olso lockutils
Or how about we add in a new log level?
A few libraries I have come across support the log level 5 (which is less than
debug (10) but greater than
On Thu, 25 Sep 2014 08:49:12 -0400
Sean Dague s...@dague.net wrote:
#1 - tried to get a lock, but someone else has it. Then we know we've
got lock contention. .
#2 - something is still holding a lock after some long amount of
time.
+1 to both.
#2 turned out to be a critical bit in
