Bug 1086223 - Blocking connection from spm to sd doesn't affect the dc status
Summary: Blocking connection from spm to sd doesn't affect the dc status
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 3.5.0
Assignee: Liron Aravot
QA Contact: Aharon Canan
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-04-10 12:02 UTC by Meital Bourvine
Modified: 2016-02-10 19:21 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-17 12:25:50 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:
amureini: needinfo+


Attachments (Terms of Use)
logs (516.31 KB, application/x-compressed-tar)
2014-04-10 12:03 UTC, Meital Bourvine
no flags Details
new logs (1.16 MB, application/x-compressed-tar)
2014-05-12 14:51 UTC, Meital Bourvine
no flags Details

Description Meital Bourvine 2014-04-10 12:02:38 UTC
Description of problem:
DC, SD, SPM status stays active/up even after blocking the connection from the SPM to the SD (there is only 1 host)

Version-Release number of selected component (if applicable):
vdsm-4.13.2-0.11.el6ev.x86_64
rhevm-3.3.1-0.48.el6ev.noarch

How reproducible:
100%

Steps to Reproduce:
1. Create a dc with a cluster and add one host and one nfs sd
2. Wait for dc to be up
3. Block connection from the spm to the nfs sd
4. Go to Data Centers tab -> the DC *isn't* up
5. Go to Storage Domains tab, click on the SD, go to Storage Domains tab -> the DC *is* up
6. Go to Hosts tab -> The spm *is* up

Actual results:
DC, SD, SPM are up

Expected results:
DC and SD will be down, SPM will be in a non-responsive state.

Comment 1 Meital Bourvine 2014-04-10 12:03:08 UTC
Created attachment 884917 [details]
logs

Comment 2 Alex Jia 2014-04-11 02:53:07 UTC
The bug will affect our automation testing, please help fix it asap, thanks.

Comment 3 Allon Mureinik 2014-04-23 13:10:00 UTC
(In reply to Meital Bourvine from comment #0)
> 5. Go to Storage Domains tab, click on the SD, go to Storage Domains tab ->
> the DC *is* up
This is the SD's SHARED STATUS, not the DC's status.

(In reply to Alex Jia from comment #2)
> The bug will affect our automation testing, please help fix it asap, thanks.
This is purely a UI issue. How can it effect automation tests?

Comment 4 Alex Jia 2014-04-24 04:45:41 UTC
(In reply to Allon Mureinik from comment #3)

> (In reply to Alex Jia from comment #2)
> > The bug will affect our automation testing, please help fix it asap, thanks.
> This is purely a UI issue. How can it effect automation tests?

Except UI issue, the host state is not expected, it is always up or connecting status after blocking connection from host to storage domain, but it's non-responsive(or non-operational) state ago, maybe, is it a regression bug? 

Meital, please help confirm this, thanks.

Comment 5 Liron Aravot 2014-04-24 08:29:01 UTC
Meital, Alex
the engine.log provided is 0 bytes :) please attach the case log.

about the raised issues - 
*Go to Data Centers tab -> the DC *isn't* up - it shouldn't be, as we don't have connectivity to the domain.

*Go to Hosts tab -> The spm *is* up
that host should remain UP, why wouldn't it be? if it wasn't we had a bug here, we have no problem communicating with it and the problem is with the storage. the question is wether it retains the SPM mark in the engine which it shouldn't.

*Go to Storage Domains tab, click on the SD, go to Storage Domains tab -> the DC is* up  - possibly a UI issue as it seems, pending needinfo? response before proceeding with it.

Comment 6 Meital Bourvine 2014-05-12 14:51:28 UTC
Couldn't reproduce exactly (the host is up with SPM, dc and sd are down).
Adding logs.

Comment 7 Meital Bourvine 2014-05-12 14:51:58 UTC
Created attachment 894760 [details]
new logs

Comment 8 Liron Aravot 2014-05-25 12:27:43 UTC
Meital, the host "SPM" role mark in the db should be released as the host isn't the spm anymore (obviously).
Perhaps thing could be improved in the engine to update the db earlier, but that's non ciritical issue that i assume we won't fix.

2014-05-12 17:47:59,466 INFO  [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (org.ovirt.thread.pool-4-thread-42) [7e42688d] Comm
and org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand return value 
 
TaskStatusListReturnForXmlRpc [mStatus=StatusForXmlRpc [mCode=654, mMessage=Not SPM: ()]]

Elad, if you can please confirm that on your env too.
Allon, if there's no other issue i assume that this one could be postponed with low severity or be closed as wont fix.


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