Bug 1456268

Summary: RESTAPI - remove storage domain using a host in maintenance is allowed causing mount on SPM to not be removed
Product: [oVirt] ovirt-engine Reporter: Avihai <aefrat>
Component: BLL.StorageAssignee: Benny Zlotnik <bzlotnik>
Status: CLOSED CURRENTRELEASE QA Contact: Avihai <aefrat>
Severity: high Docs Contact:
Priority: unspecified    
Version: 4.1.2.2CC: amureini, bugs
Target Milestone: ovirt-4.2.0Keywords: Automation
Target Release: ---Flags: rule-engine: ovirt-4.2+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: No Doc Update
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-20 10:49:10 UTC 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
engine & vdsm logs none

Description Avihai 2017-05-28 14:32:28 UTC
Created attachment 1283027 [details]
engine & vdsm logs

Description of problem:
Via rest API it is possible to remove a storage domain using a host in maintenance .
This cause for the SPM not to umount the mount to the storage domain & if we recreate the same SD the SPM will not remount & mount options will be lost . 


Version-Release number of selected component (if applicable):
Engine:
4.1.2.2

VDSM:
4.19.15-1

How reproducible:
100%


Steps to Reproduce:

Setup:
2 hosts:
host_mixed_1 in maintenance .
host_mixed_2 is active & SPM .

1.Create storage domain via API on SPM host:

Method :
POST

URL:
https://storage-ge-01.scl.lab.tlv.redhat.com/ovirt-engine/api/storagedomains

Body :

<storage_domain>
<name>t1</name>
    <storage>
        <address>gluster-server01.qa.lab.tlv.redhat.com</address>
        <path>/storage_local_ge4_replica_3</path>
        <type>glusterfs</type>
        <vfs_type>glusterfs</vfs_type>
    </storage>
    <storage_format>v4</storage_format>
    <type>data</type>
    <host>
        <name>host_mixed_2</name>
    </host>
</storage_domain>


2. See that mount is added to SPM :
gluster-server01.qa.lab.tlv.redhat.com:/storage_local_ge4_replica_3 on /rhev/data-center/mnt/glusterSD/gluster-server01.qa.lab.tlv.redhat.com:_storage__local__ge4__replica__3 type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)


3. remove + format storage doamin :

DELETE method from host in maintenance (host = host_mixed_1) :
https://storage-ge-04.scl.lab.tlv.redhat.com/ovirt-engine/api/storagedomains/9f87c7bf-3695-4e02-bf6d-8c7d75180bf7;host=host_mixed_1;format=True

Actual results:
Storage is removed but the mount is still there! 

In SPM vdsm log NO umount is seen , but in maintanacne host vdsm log umount is seen :
2017-05-28 17:15:25,993+0300 INFO  (jsonrpc/7) [storage.Mount] unmounting /rhev/data-center/mnt/glusterSD/gluster-server01.qa.lab.tlv.redhat.com:_storage__local__ge4__replica__3 (mount:195)


• This causes issues as if you recreate the storage with the same path but with different mount options, this will not be implemented.

Expected results:
Either it should NOT be allowed to delete storage domain from the host in maintenance/Non-active state.

OR

If prior is allowed make sure SPM active host should be updated as well & umount to SD should occur on SPM.

Additional info:

timeline :
May 28, 2017 5:13:01 PM
Storage Domain t1 was added by admin@internal-authz

May 28, 2017 5:15:27 PM
Storage Domain t1 was removed by admin@internal-authz

mount | grep replica
gluster-server01.qa.lab.tlv.redhat.com:/storage_local_ge4_replica_3 on /rhev/data-center/mnt/glusterSD/gluster-server01.qa.lab.tlv.redhat.com:_storage__local__ge4__replica__3 type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)

Comment 1 Avihai 2017-07-06 04:44:15 UTC
verified on 4.2.0-0.0.master.20170702100738.git46a9f67.el7.centos

Comment 2 Sandro Bonazzola 2017-12-20 10:49:10 UTC
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.