Bug 879322 - engine: engine log reports domain as problematic with WARN log level and than deactivates it with INFO log level
Summary: engine: engine log reports domain as problematic with WARN log level and tha...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.1.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
: 3.2.0
Assignee: Alissa
QA Contact: Elad
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-11-22 15:36 UTC by Dafna Ron
Modified: 2016-02-10 20:24 UTC (History)
11 users (show)

Fixed In Version: SF6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
logs (706.57 KB, application/x-gzip)
2012-11-22 15:36 UTC, Dafna Ron
no flags Details

Description Dafna Ron 2012-11-22 15:36:46 UTC
Created attachment 649874 [details]
logs

Description of problem:

when there is a problem with iso domain we show alert in log as WARN and than deactivate the domain. 

2012-11-22 17:15:28,495 WARN  [org.ovirt.engine.core.vdsbroker.irsbroker.IrsBrokerCommand] (QuartzScheduler_Worker-70) domain eebcad17-cbf7-4098-880d-81e2c2504169:shared_iso_domain was reported by all hosts in status UP as problematic. Moving the Domain to NonOperational.
2012-11-22 17:15:28,598 INFO  [org.ovirt.engine.core.bll.storage.DeactivateStorageDomainCommand] (QuartzScheduler_Worker-70) [7bfa2d45] Lock Acquired to object EngineLock [exclusiveLocks= key: eebcad17-cbf7-4098-880d-81e2c2504169 value: STORAGE
, sharedLocks= ]
2012-11-22 17:15:28,640 INFO  [org.ovirt.engine.core.bll.storage.DeactivateStorageDomainCommand] (QuartzScheduler_Worker-70) [7bfa2d45] Running command: DeactivateStorageDomainCommand internal: true. Entities affected :  ID: eebcad17-cbf7-4098-880d-81e2c2504169 Type: Storage
2012-11-22 17:15:28,698 INFO  [org.ovirt.engine.core.bll.storage.DeactivateStorageDomainCommand] (QuartzScheduler_Worker-70) [7bfa2d45] Lock freed to object EngineLock [exclusiveLocks= key: eebcad17-cbf7-4098-880d-81e2c2504169 value: STORAGE
, sharedLocks= ]


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

si24.4

How reproducible:

100%

Steps to Reproduce:
1. block communication to only the iso domain from all the hosts
2.
3.
  
Actual results:

vdsm reports that domain does not exist and engine reports the domain as problematic in WARN entry and than deactivates the domain with INFO log level. 

Expected results:

deactivation of a domain because its problematic should be with log level of ERROR. 

Additional info: logs

Comment 1 Allon Mureinik 2012-12-18 16:12:30 UTC
If anything, the message about the blocked domain should be ERROR instead of WARN, but not sure about that either.

Disconnecting is the way we deal with it, which IMHO is an information message only.

Comment 2 Ayal Baron 2012-12-19 10:50:19 UTC
Ack on changing WARN to ERROR.
Ack on changing message to state *why* we are deactivating the domain.
The deactivation message should remain INFO as that is all it is.

Comment 3 Alissa 2013-01-03 16:34:27 UTC
(In reply to comment #2)
> Ack on changing WARN to ERROR.
> Ack on changing message to state *why* we are deactivating the domain.
> The deactivation message should remain INFO as that is all it is.

After speaking with Ayal - the message will not be changed, its content is correct. The only change that will be made is changing warn to error .

Comment 4 Alissa 2013-01-03 17:05:51 UTC
submitted patch
http://gerrit.ovirt.org/#/c/10636/

Comment 6 Elad 2013-02-20 16:01:51 UTC
I tested on SF7:
The WARN log was changed to ERROR but the inactive domain is still in INFO log:

2013-02-20 17:45:12,211 INFO  [org.ovirt.engine.core.bll.storage.DeactivateStorageDomainCommand] (pool-3-thread-50) [389e0085] Running command: DeactivateStorageDomainCommand internal: true
. Entities affected :  ID: eebcad17-cbf7-4098-880d-81e2c2504169 Type: Storage

Comment 7 Allon Mureinik 2013-02-21 07:00:52 UTC
Elad, please see comment 2 - this is the expected behavior

Comment 8 Itamar Heim 2013-06-11 08:56:18 UTC
3.2 has been released

Comment 9 Itamar Heim 2013-06-11 08:56:18 UTC
3.2 has been released

Comment 10 Itamar Heim 2013-06-11 08:56:30 UTC
3.2 has been released

Comment 11 Itamar Heim 2013-06-11 08:59:00 UTC
3.2 has been released

Comment 12 Itamar Heim 2013-06-11 09:28:26 UTC
3.2 has been released


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