Description of problem: After a peer probe from the cluster to a new server, a replace-brick on either the new server, or any other existing server in the cluster, fails if the new server cannot (DNS) resolve the old server. replace-brick commit force bails out with : brick: oldserver:/brick/a does not exist in volume: vol01 Version-Release number of selected component (if applicable): 3.3git-v3.3.2qa2-1-g45a9d1e Actual results: brick: oldserver:/brick/a does not exist in volume: vol01 Expected results: replace-brick commit-force should work. the oldserver is irrelevant (and down in my case)
Still happening on GlusterFS 3.7. I created a 3 node cluster (gfs1, gfs2, gfs3), 3 bricks each, then killed gfs2. I added a 4th host (gfs4) and used "peer probe" to add it to the cluster. I can't detach gfs2 because it has bricks in the cluster, and I can't replace gfs2 bricks with gfs4 bricks because it claims that the gfs2 bricks don't exist. Check it out: root@gfs1:~# gluster volume info Volume Name: volume1 Type: Distributed-Replicate Volume ID: 168a6859-91a5-451e-9c32-ab531b79df16 Status: Started Number of Bricks: 3 x 3 = 9 Transport-type: tcp Bricks: Brick1: gfs1:/data/brick1/files Brick2: gfs2:/data/brick1/files Brick3: gfs3:/data/brick1/files Brick4: gfs1:/data/brick2/files Brick5: gfs2:/data/brick2/files Brick6: gfs3:/data/brick2/files Brick7: gfs1:/data/brick3/files Brick8: gfs2:/data/brick3/files Brick9: gfs3:/data/brick3/files Options Reconfigured: nfs.disable: off features.quota-deem-statfs: on features.inode-quota: on features.quota: on performance.readdir-ahead: on root@gfs1:~# gluster volume replace-brick volume1 gfs2:/data/brick1/files gfs4:/data/brick1/files commit force volume replace-brick: failed: brick: gfs2:/data/brick1/files does not exist in volume: volume1 I worked around the problem by adding gfs2 to /etc/hosts on gfs1, gfs3, and gfs4. Once I did that I could replace the bricks.
pre-release 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.
Kaleb: You might have the ability to re-open this bug or set the version number, I do not. I did state that the problem is still present with GlusterFS 3.7 in my comment above.
Well, I can't reopen this bug, but I can clone it, so I did. Cloned copy can be found as https://bugzilla.redhat.com/show_bug.cgi?id=1275884