Bug 1311234 - backup-volfile-servers queried on every remount of gluster storage domain
backup-volfile-servers queried on every remount of gluster storage domain
Status: CLOSED WONTFIX
Product: vdsm
Classification: oVirt
Component: Gluster (Show other bugs)
4.17.18
Unspecified Unspecified
medium Severity medium (vote)
: ovirt-4.2.0
: ---
Assigned To: Ala Hino
SATHEESARAN
:
: 1311235 (view as bug list)
Depends On:
Blocks: Gluster-HC-3
  Show dependency treegraph
 
Reported: 2016-02-23 11:45 EST by Sahina Bose
Modified: 2017-09-12 08:23 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-09-12 08:23:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
sabose: ovirt‑4.2?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description Sahina Bose 2016-02-23 11:45:31 EST
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 03:07:42 EST
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 03:08:35 EST
*** Bug 1311235 has been marked as a duplicate of this bug. ***
Comment 3 Yaniv Kaul 2016-03-21 10:28:36 EDT
(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 02:13:52 EDT
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 10:20:45 EDT
(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 11:20:18 EST
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 08:23:53 EDT
(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.

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