Bug 1311234

Summary:	backup-volfile-servers queried on every remount of gluster storage domain
Product:	[oVirt] vdsm	Reporter:	Sahina Bose <sabose>
Component:	Gluster	Assignee:	Ala Hino <ahino>
Status:	CLOSED WONTFIX	QA Contact:	SATHEESARAN <sasundar>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.17.18	CC:	amureini, bugs, sabose
Target Milestone:	---	Flags:	sbonazzo: ovirt-4.2-
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-09-12 12:23:53 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:
Bug Blocks:	1411323

Description Sahina Bose 2016-02-23 16:45:31 UTC

Description of problem:
When gluster volume is used as storage domain and mount path given as server1:/vol1, the volfile is fetched from server1 to introspect the possible  alternative servers (say, server2, server3). These servers are then passed as mount option "backup-volfile-servers=server2:server3".

However since the backup-volfile-servers option is not persisted, each time vdsm tries to mount the storage domain, the primary server (server1) is queried and activation of storage domain fails if primary server is down - even though the other servers in cluster are available.


The alternative backup servers should be persisted in DB the first time, and used in subsequent mount calls

Comment 1 Allon Mureinik 2016-02-24 08:07:42 UTC

Doing this will make VDSM oblivious to changes on the gluster side. I don't think it's a good idea.

Comment 2 Allon Mureinik 2016-02-24 08:08:35 UTC

*** Bug 1311235 has been marked as a duplicate of this bug. ***

Comment 3 Yaniv Kaul 2016-03-21 14:28:36 UTC

(In reply to Allon Mureinik from comment #1)
> Doing this will make VDSM oblivious to changes on the gluster side. I don't
> think it's a good idea.

Sahina - CLOSE-WONTFIX?

Comment 4 Sahina Bose 2016-03-22 06:13:52 UTC

If we close this, we are essentially removing the support for using backup-volfile-servers. 
I think whenever gluster volfile changes are detected, the DB should be updated either automatically, or via user initiated action.

Comment 5 Allon Mureinik 2016-03-22 14:20:45 UTC

(In reply to Sahina Bose from comment #4)
> If we close this, we are essentially removing the support for using
> backup-volfile-servers. 
> I think whenever gluster volfile changes are detected, the DB should be
> updated either automatically, or via user initiated action.

This is the the same situation we had before integrating backup-volfile-servers, so there's no urgency here.

This should be separated into two issues:
- In HC, VDSM shouldn't detect anything anyway - the engine also manages the volume, so it should send the proper configuration on each connectStorageServer request.
- In a non-HC environment this would mean new verbs for the engine to query the gluster topology, store it somehow, and send it on each connectStorageServer request. Looks like a lot of work for a very small benefit, if any. Definitely not 4.0 material, at least not with the given timeframe and capacity.

Comment 6 Sahina Bose 2017-01-09 16:20:18 UTC

Defering this as https://bugzilla.redhat.com/show_bug.cgi?id=1177782 has a way of persisting backup-volfile-server info in engine, if storage domain is linked to gluster volume

Comment 7 Allon Mureinik 2017-09-12 12:23:53 UTC

(In reply to Sahina Bose from comment #6)
> Defering this as https://bugzilla.redhat.com/show_bug.cgi?id=1177782 has a
> way of persisting backup-volfile-server info in engine, if storage domain is
> linked to gluster volume
This seems good enough to me, closing.