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
Doing this will make VDSM oblivious to changes on the gluster side. I don't think it's a good idea.
*** Bug 1311235 has been marked as a duplicate of this bug. ***
(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?
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.
(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.
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
(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.