Bug 1373930

Summary: [RFE][HC] Expose mount options under getStorageDomainInfo verb (for DR and hosted engine)
Product: Red Hat Enterprise Virtualization Manager Reporter: Roy Golan <rgolan>
Component: vdsmAssignee: Fred Rolland <frolland>
Status: CLOSED ERRATA QA Contact: Nikolai Sednev <nsednev>
Severity: high Docs Contact:
Priority: high    
Version: 2.1.0CC: bugs, frolland, lsurette, msivak, nsednev, phbailey, ratamir, srevivo, stirabos, tnisan, ycui, ykaul, ylavi
Target Milestone: ovirt-4.2.0Keywords: FutureFeature, Improvement, Reopened, Triaged
Target Release: ---Flags: ratamir: testing_plan_complete-
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: dr
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-15 17:49:33 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:
Bug Depends On: 1393902    
Bug Blocks: 1435570    

Description Roy Golan 2016-09-07 12:57:41 UTC
Description of problem:
The mount options used to mount a domain can be useful for DR and hosted engine management, when we want to reconstruct the exact connection details in the engine.

See Bug 1263603 for the hosted engine use-case


- Example of the current verb output:

```bash

vdsClient -s 0 getStorageDomainInfo X
uuid = X
	version = 3
	role = Regular
	remotePath = lago_he_basic_suite_4_0_storage:/exports/nfs_he
	type = NFS
	class = Data
	pool = ['00000001-0001-0001-0001-000000000148']
	name = hosted_storage
```

- the actual kernel mount options

```bash
cat /proc/mounts | grep 'exports/nfs_he'
lago_he_basic_suite_4_0_storage:/exports/nfs_he /rhev/data-center/mnt/lago__he__basic__suite__4__0__storage:_exports_nfs__he nfs rw,relatime,vers=3,rsize=262144,wsize=262144,namlen=255,soft,nosharecache,proto=tcp,timeo=600,retrans=6,sec=sys,mountaddr=192.168.200.2,mountvers=3,mountport=20048,mountproto=udp,local_lock=none,addr=192.168.200.2 0 0

```



Based on that

Comment 1 Roy Golan 2016-09-07 12:59:21 UTC
correction- the related Bug is 1263602

Comment 2 Allon Mureinik 2016-09-25 11:19:59 UTC
The attached patch was abandoned, returning to NEW.
We need to redesign the solution for this requirement.

Comment 6 Allon Mureinik 2017-09-14 15:37:41 UTC
Need to see if this is still relevant in the new HE flow.

Comment 7 Yaniv Lavi 2017-11-06 09:28:28 UTC
Does the node zero hosted engine work remove the need for this RFE?

Comment 8 Fred Rolland 2017-11-09 10:16:41 UTC
Martin,
Do you need this RFE for Hosted Engine?

Comment 9 Martin Sivák 2017-11-09 11:11:37 UTC
Node 0 does not need it, the old flow does. Closing this depends on the amount of love we want to give to the old flow now.

Comment 10 Yaniv Lavi 2017-11-09 11:18:01 UTC
Closing based on comment #9.

Comment 11 Martin Sivák 2018-02-09 10:41:55 UTC
Yaniv, this or some kind of a tool might be needed to allow already deployed pre-Node 0 environments to work properly once we remove all the (administrative) SD restrictions. Like putting a non-HE disk on HE storage domains. Engine will not be able to mount the SD on non HE host if non-standard mount options are needed.

Comment 12 Yaniv Lavi 2018-02-14 12:54:13 UTC
(In reply to Martin Sivák from comment #11)
> Yaniv, this or some kind of a tool might be needed to allow already deployed
> pre-Node 0 environments to work properly once we remove all the
> (administrative) SD restrictions. Like putting a non-HE disk on HE storage
> domains. Engine will not be able to mount the SD on non HE host if
> non-standard mount options are needed.

We didn't support this prior to 4.2, so any such bugs would be not a bug.
Special mount options are a 4.2 feature, because of the things you mentioned.

Comment 13 Yaniv Kaul 2018-03-12 08:33:35 UTC
(In reply to Yaniv Lavi from comment #12)
> (In reply to Martin Sivák from comment #11)
> > Yaniv, this or some kind of a tool might be needed to allow already deployed
> > pre-Node 0 environments to work properly once we remove all the
> > (administrative) SD restrictions. Like putting a non-HE disk on HE storage
> > domains. Engine will not be able to mount the SD on non HE host if
> > non-standard mount options are needed.
> 
> We didn't support this prior to 4.2, so any such bugs would be not a bug.
> Special mount options are a 4.2 feature, because of the things you mentioned.

Do we expose the mount options under 'Advanced' in Cockpit? If we do, and we pass it along, please move this to ON_QA.

Comment 14 Phillip Bailey 2018-03-12 13:57:49 UTC
(In reply to Yaniv Kaul from comment #13)
> Do we expose the mount options under 'Advanced' in Cockpit? If we do, and we
> pass it along, please move this to ON_QA.

Mount options are configurable in Cockpit and are passed in the var files, but the field is not in the advanced section. Moving to ON_QA, as requested.

Comment 21 Avihai 2018-03-28 08:28:22 UTC
Hi Fred,

I did not get a replay from Simone until now(10 days ago), 
Is there anyone else who can help to understand if this bug was fixed or not?

From my POV bug is still there as both bug's headline ('Expose mount options under getStorageDomainInfo verb') and original description of this bug clearly state what is the expected fix.

If the verification scenario is not to check via getStorageDomainInfo verb that mount options are there then please provide the revised verification scenario. 

Please advise how to proceed here.

Comment 22 Simone Tiraboschi 2018-03-28 09:34:00 UTC
(In reply to Avihai from comment #21)
Sorry for the delay, I missed this.

According to comments 9, 12, 13, 14 we decided to avoid fixing it on VDSM side.

In the new ansible based flow, the storage domain is going to be create over a locally running engine via REST APIs and we are passing additional mount options there.
No need to infer or detect them at auto import time since in this new flow we don't have any auto import process for the hosted-engine storage domain.

In order to verify it, deploy hosted-engine from CLI and/or from the cockpit wizard. Both of the two should let you enter additional mount options from the storage domain.
At the end of the deployment check storage domain details, the additional mount options should be there.

Comment 23 Nikolai Sednev 2018-03-28 14:21:19 UTC
Node 0 works fine with mounting options on these components for CLI/Cockpit:
ovirt-hosted-engine-setup-2.2.15-1.el7ev.noarch
ovirt-hosted-engine-ha-2.2.9-1.el7ev.noarch
rhvm-appliance-4.2-20180202.0.el7.noarch
cockpit-160-3.el7.x86_64
cockpit-ovirt-dashboard-0.11.19-1.el7ev.noarch
Linux 3.10.0-862.el7.x86_64 #1 SMP Wed Mar 21 18:14:51 EDT 2018 x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux Server release 7.5 (Maipo)

Deployment with these options works fine over NFS:
[ INFO  ] changed: [localhost]
          Please specify the storage you would like to use (glusterfs, iscsi, fc, nfs)[nfs]: nfs
          Please specify the nfs version you would like to use (auto, v3, v4, v4_1)[auto]: v4
          Please specify the full shared storage connection path to use (example: host:/path): yellow-vdsb.qa.lab.tlv.redhat.com:/Compute_NFS/nsednev_he_1
          If needed, specify additional mount options for the connection to the hosted-engine storagedomain []: rsize=32768,wsize=32768

After deployment I've checked that mounting option was clearly seen in "Storage->Domains->Manage Domain->Custom Connection Parameters" on hosted_storage.

Please feel free to reopen if you feel that there is still missing options for this RFE.

Comment 26 errata-xmlrpc 2018-05-15 17:49:33 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

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

https://access.redhat.com/errata/RHEA-2018:1489

Comment 27 Franta Kust 2019-05-16 13:07:46 UTC
BZ<2>Jira Resync