Bug 1128824 - Deactivating master storage domain is allowed while other domains are in preparing_for_maintenance status
Summary: Deactivating master storage domain is allowed while other domains are in prep...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.5
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
: 3.5.0
Assignee: Federico Simoncelli
QA Contact: Carlos Mestre González
URL:
Whiteboard: storage
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-11 15:25 UTC by Carlos Mestre González
Modified: 2016-02-10 18:18 UTC (History)
9 users (show)

Fixed In Version: ovirt-3.5.0_rc2
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-22 08:19:11 UTC
oVirt Team: Storage


Attachments (Terms of Use)
vdsm.log for vt3.1 (1.47 MB, text/plain)
2014-09-16 10:01 UTC, Carlos Mestre González
no flags Details


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 32517 master MERGED core: check storage domains status on master deactivation Never
oVirt gerrit 32794 ovirt-engine-3.5 MERGED core: check storage domains status on master deactivation Never

Description Carlos Mestre González 2014-08-11 15:25:29 UTC
Description of problem:
Is possible to deactive a master domain while other domains (tested for export domain and second data domains) are in preparing_for_maintenance. Both operation succeed, but the export domain is in status "preparing_for_maintenance", so maybe should be allow but the status must be updated properly.

Version-Release number of selected component (if applicable):
ovirt-engine-3.5.0-0.0.master.20140804172041. (ovirt RC1)

How reproducible:
100%

Steps to Reproduce:
1. Have a DC with a master domain (NFS) and a export domain active
2. Deactivate export domain
3. While the export domain is being deactivated (status is prepare_for_maintenance") try to deactivate the master domain.

Actual results:
Master domain is deactivated, and the export domain is in "preparing_for_maintenance" permanently, vdsm is running 

updateState) Task=`e61366a7-099c-4d66-afd6-6feb2654882c`::moving from state init -> state preparing

all the time.
Seems the problem is the status is not updated in the db.

Expected results:
I expect to master domain to not be deactivated until the export domain is too, or at least it will set the proper status for the export domain.

Additional info:
Checking the vdsm logs there's an error umounting the master domain /usr/share/vdsm/storage/mount.py (tough the operation succeeded, master domain is umounted and on status maintenance).

Comment 2 Carlos Mestre González 2014-08-11 15:36:11 UTC
(In reply to Carlos Mestre González from comment #0)
> Additional info:
> Checking the vdsm logs there's an error umounting the master domain
> /usr/share/vdsm/storage/mount.py (tough the operation succeeded, master
> domain is umounted and on status maintenance).

Forget about this, everything seems fine in the log, the only problem is the status for the export domain is never changed to maintenance.

Comment 3 Allon Mureinik 2014-08-11 15:39:05 UTC
Carlos, can you attach engine+vdsm logs please?

Comment 4 Allon Mureinik 2014-08-11 15:39:43 UTC
(In reply to Allon Mureinik from comment #3)
> Carlos, can you attach engine+vdsm logs please?
Disregard - you beat me to it :-)

Comment 6 Carlos Mestre González 2014-09-16 09:54:14 UTC
I've tried to verified this in vt3.1, and is not working. Same issue that state in the bug description, export_domain is in 'preparing for maintenance' since the umount failed (adding vdsm.log)

Comment 7 Carlos Mestre González 2014-09-16 10:01:08 UTC
Created attachment 937921 [details]
vdsm.log for vt3.1

last 5 minutes can see the error

Comment 8 Allon Mureinik 2014-09-16 10:01:52 UTC
RHEVM's vt3.1 is older than oVirt's RC2 (and moreover, oVirt bugs should be verified with oVirt versions).

Moving back to ON_QA to verify with the right version.

Comment 9 Aharon Canan 2014-09-16 10:03:19 UTC
you are right about rc2 but not that we need to verify ovirt bugs on ovirt, we can and verify on both.

Comment 10 Allon Mureinik 2014-09-16 11:05:15 UTC
(In reply to Aharon Canan from comment #9)
> but not that we need to verify ovirt bugs on ovirt,
> we can and verify on both.
Of course not.
If it's not part of an oVirt build, it's meaningless to a oVirt users.

Comment 11 Aharon Canan 2014-09-22 08:19:11 UTC
easy workaround, we can reactivate the master domain and the export enter maintenance


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