Bug 882671 - PRD32 - if a host doesn't see any storage domains, it should move to none-operational - even if it is the last host up
Summary: PRD32 - if a host doesn't see any storage domains, it should move to none-ope...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.3.0
Assignee: mkublin
QA Contact: vvyazmin@redhat.com
URL:
Whiteboard: infra
Depends On: 912054
Blocks: 915537
TreeView+ depends on / blocked
 
Reported: 2012-12-02 15:24 UTC by Barak
Modified: 2016-02-10 19:39 UTC (History)
12 users (show)

Fixed In Version: sf3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-27 11:35:17 UTC
oVirt Team: Infra
Target Upstream Version:


Attachments (Terms of Use)
## Logs vdsm, rhevm (2.78 MB, application/x-gzip)
2013-02-06 14:30 UTC, vvyazmin@redhat.com
no flags Details
## Logs vdsm, rhevm (iSCSI) (1.81 MB, application/x-gzip)
2013-02-06 14:31 UTC, vvyazmin@redhat.com
no flags Details

Description Barak 2012-12-02 15:24:22 UTC
This is a part of the solution to resolve a series of issues related to "last host in up" and as a result of discussions done about Bug 869309.

The idea is that when the last host in up does not see any SDs it should move to none-operational.

There is a different bug to enable using a none-operational host as fence proxy when the reason is not network (Bug 876235)

Comment 5 Barak 2012-12-06 13:55:51 UTC
This was actually fixed on upstream by commit 
http://gerrit.ovirt.org/#/c/9566/

The above commit solves also Bug 844350

Hence moving to POST, I don't close as duplicate as I would like the 2 issues to be tested.

Comment 6 mkublin 2012-12-19 11:51:24 UTC
Not exactly understand requirements.
What I did:
1. If host can not connect to pool it will not moved to status UP, event it is a only host in pool.
2. If we performed a failover and we deactivated a last storage domain , the pool should be moved to Maintenance. When pool in maintenance status no failover process should run. These is a intention in code at least for last 2 years (code is written in such way, can be seen in DeactivateStorageDomainCommand). If it is not working in a such way it is a bug.

Comment 7 Stephen Gordon 2013-01-03 21:46:46 UTC
Setting docs_scoped- here, as per comment # 6 it seems like what is actually happening here is we are fixing a regression that was introduced when we added the autorecovery paths. I don't think there is any documentation impact here.

Comment 8 vvyazmin@redhat.com 2013-02-06 14:30:06 UTC
Failed on RHEVM 3.2 - SF05 environment (FC and iSCSI):

RHEVM: rhevm-3.2.0-6.el6ev.noarch
VDSM: vdsm-4.10.2-5.0.el6ev.x86_64
LIBVIRT: libvirt-0.10.2-17.el6.x86_64
QEMU & KVM: qemu-kvm-rhev-0.12.1.2-2.348.el6.x86_64
SANLOCK: sanlock-2.6-2.el6.x86_64


Steps to Reproduce:
1. Create FC or iSCSI DC environment with two hosts
2. Create a multiple SD's
3. From first host, block connection to all SD's
4. From second host, block connection to SD's, except one SD
5. From second host, block connection to last SD

Second host stay in status UP.

Comment 9 vvyazmin@redhat.com 2013-02-06 14:30:50 UTC
Created attachment 693959 [details]
## Logs vdsm, rhevm

Comment 10 vvyazmin@redhat.com 2013-02-06 14:31:29 UTC
Created attachment 693960 [details]
## Logs vdsm, rhevm (iSCSI)

Comment 11 mkublin 2013-02-06 15:05:09 UTC
Like I wrote, I did not understand requirements and what I did:

1. If host can not connect to pool it will not moved to status UP, event it is a only host in pool.
2. If we performed a failover and we deactivated a last storage domain , the pool should be moved to Maintenance. When pool in maintenance status no failover process should run. These is a intention in code at least for last 2 years (code is written in such way, can be seen in DeactivateStorageDomainCommand). If it is not working in a such way it is a bug.

I did not solve a case described here and I had not any intention to do these

Comment 12 mkublin 2013-02-17 13:50:32 UTC
Actually only when all domains are Inactive, I can move host to NonOperationals

Comment 13 Ayal Baron 2013-05-02 20:24:53 UTC
Barak, isn't this bug irrelevant in light of the changes Liron made in the lifecycle?

Comment 14 Barak 2013-05-27 11:35:17 UTC
I agree with comment #13, this bug is not relevant any more,
As we chose a different path to solve the various issues with the host life-cycle.

Hence moving this bug to CLOSE NOTABUG


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