Bug 879322

Summary: engine: engine log reports domain as problematic with WARN log level and than deactivates it with INFO log level
Product: Red Hat Enterprise Virtualization Manager Reporter: Dafna Ron <dron>
Component: ovirt-engineAssignee: Alissa <abonas>
Status: CLOSED CURRENTRELEASE QA Contact: Elad <ebenahar>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.1.0CC: abaron, amureini, dyasny, hateya, iheim, lpeer, Rhev-m-bugs, sgrinber, thildred, yeylon, ykaul
Target Milestone: ---   
Target Release: 3.2.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: storage
Fixed In Version: SF6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
logs none

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