Bug 741103 - VDSM: the Thread for getStoragePoolInfo should be diminished -> it creates noise in the log every 10 seconds
VDSM: the Thread for getStoragePoolInfo should be diminished -> it creates no...
Status: CLOSED WONTFIX
Product: oVirt
Classification: Community
Component: vdsm (Show other bugs)
unspecified
x86_64 Linux
unspecified Severity medium
: ---
: 3.3.4
Assigned To: Dan Kenigsberg
storage
: Improvement
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-25 07:31 EDT by Dafna Ron
Modified: 2015-01-24 05:34 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-12 05:38:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
vdsm log attached (494.84 KB, application/x-gzip)
2011-09-25 07:31 EDT, Dafna Ron
no flags Details

  None (edit)
Description Dafna Ron 2011-09-25 07:31:56 EDT
Created attachment 524783 [details]
vdsm log attached

Description of problem:

The thread for getStoragePoolInfo contains about 19 lines each time it runs (which is every 10 seconds) out of these 10 lines about 10 are for ResourceManager. 
can you please diminish some of these lines from logger to clean the log a bit?
it feels like since this runs every 10 seconds that some of these actions might not need to be in the log. 


Version-Release number of selected component (if applicable):

vdsm-4.9-96.1.el6.x86_64

How reproducible:

100% 

Steps to Reproduce:
1. search for getStoragePoolInfo in the vdsm log
2.
3.
  
Actual results:

the query runs every 10 seconds and logs about 19 raws each time 

Expected results:

can we please remove some of these raws from vdsm log since it seems like a lot of noise in the log for one query. 

Additional info:
Comment 1 Yaniv Kaul 2011-09-25 09:45:39 EDT
Specifically, the issue is with the lines from the ResourceManager. They represent 10 lines of logs out of the total 19 of the command. Example:
Thread-2000::DEBUG::2011-09-25 13:01:02,104::resourceManager::821::ResourceManager.Owner::(cancelAll) Owner.cancelAll requests {}
Thread-2000::DEBUG::2011-09-25 13:01:02,104::resourceManager::517::ResourceManager::(releaseResource) Trying to release resource 'Storage.0b8809e9-1f75-40d7-9d32-8b66969ff552'
Thread-2000::DEBUG::2011-09-25 13:01:02,104::resourceManager::532::ResourceManager::(releaseResource) Released resource 'Storage.0b8809e9-1f75-40d7-9d32-8b66969ff552' (0 active users)
Thread-2000::DEBUG::2011-09-25 13:01:02,105::resourceManager::537::ResourceManager::(releaseResource) Resource 'Storage.0b8809e9-1f75-40d7-9d32-8b66969ff552' is free, finding out if anyone is waiting for it.
Thread-2000::DEBUG::2011-09-25 13:01:02,105::resourceManager::544::ResourceManager::(releaseResource) No one is waiting for resource 'Storage.0b8809e9-1f75-40d7-9d32-8b66969ff552', Clearing records.
Comment 3 Dan Kenigsberg 2011-09-25 10:55:59 EDT
I'm very glad that you are confident in our bugless deadlockless resource subsystem. I'm a little less confident, and would like to keep the log lines, just in case a complex deadlock crops up in a customer site. Let's reconsider in 3.1, and use `grep -v ::ResourceManager::` until then.
Comment 4 Itamar Heim 2013-03-12 05:38:03 EDT
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.

Note You need to log in before you can comment on or make changes to this bug.