Bug 765437 - (GLUSTER-3705) [FEAT] Use uuid in volume info file for servers instead of hostname or ip address
[FEAT] Use uuid in volume info file for servers instead of hostname or ip add...
Status: CLOSED DEFERRED
Product: GlusterFS
Classification: Community
Component: glusterd (Show other bugs)
mainline
All Linux
medium Severity low
: ---
: ---
Assigned To: bugs@gluster.org
: FutureFeature, Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-05 14:39 EDT by Joe Julian
Modified: 2017-08-15 12:37 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-15 12:37:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Github https://github.com/gluster/glusterd2/issues/356 None None None 2017-08-15 12:36 EDT

  None (edit)
Description Joe Julian 2011-10-05 14:39:50 EDT
In the volume info file, if the servers were referenced by uuid if the hostnames or ip addresses of the hosts change, the bricks would still reference the correct machine.

In the IRC channel today, we had someone whose network had been renumbered. He had created his volumes using IP addresses instead of hostnames. He was able to peer probe which changed the host information to accurately reflect the new ip addresses, but the volumes still pointed at the old addresses. They could not run replace-brick to update the addresses of their bricks.

If the bricks were referenced by host uuid, the peer probe would have allowed the bricks to resolve to the new information without further changes.
Comment 1 Kaleb KEITHLEY 2015-10-22 11:46:38 EDT
because of the large number of bugs filed against mainline version\ is ambiguous and about to be removed as a choice.

If you believe this is still a bug, please change the status back to NEW and choose the appropriate, applicable version for it.
Comment 3 Logos01 2016-02-04 19:55:13 EST
I myself encountered a situation where this feature would have prevented a disruption in my gluster volumes' availability after a hostname-change. Although detaching and re-attaching the peer was successful against the new hostname, at some point it reverted to the old hostname (which was to a different IP address), and my brick-hosts became detached as a result.
Comment 4 Kaushal 2017-03-08 05:55:48 EST
This bug is getting closed because GlusteFS-3.7 has reached its end-of-life.

Note: This bug is being closed using a script. No verification has been performed to check if it still exists on newer releases of GlusterFS.
If this bug still exists in newer GlusterFS releases, please reopen this bug against the newer release.
Comment 5 Atin Mukherjee 2017-08-15 10:37:44 EDT
We are thinking of addressing it in GD2, github reference https://github.com/gluster/glusterd2/issues/356 . 

Joe - since we don't have plan to fix this in current form of glusterd, do you have any objection if we close this bug and track it through the github reference mentioned?
Comment 6 Joe Julian 2017-08-15 12:37:26 EDT
Closing in favor of the github issue.

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