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
PRD32 - if a host doesn't see any storage domains, it should move to none-ope...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.1.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.3.0
Assigned To: mkublin
vvyazmin@redhat.com
infra
:
Depends On: 912054
Blocks: 915537
  Show dependency treegraph
 
Reported: 2012-12-02 10:24 EST by Barak
Modified: 2016-02-10 14:39 EST (History)
12 users (show)

See Also:
Fixed In Version: sf3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-05-27 07:35:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Barak 2012-12-02 10:24:22 EST
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 08:55:51 EST
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 06:51:24 EST
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 16:46:46 EST
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 09:30:06 EST
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 09:30:50 EST
Created attachment 693959 [details]
## Logs vdsm, rhevm
Comment 10 vvyazmin@redhat.com 2013-02-06 09:31:29 EST
Created attachment 693960 [details]
## Logs vdsm, rhevm (iSCSI)
Comment 11 mkublin 2013-02-06 10:05:09 EST
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 08:50:32 EST
Actually only when all domains are Inactive, I can move host to NonOperationals
Comment 13 Ayal Baron 2013-05-02 16:24:53 EDT
Barak, isn't this bug irrelevant in light of the changes Liron made in the lifecycle?
Comment 14 Barak 2013-05-27 07:35:17 EDT
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.