[Bugs] [Bug 1203135] New: geo-replication spuriously ignores FQDN

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1203135

            Bug ID: 1203135
           Summary: geo-replication spuriously ignores FQDN
           Product: GlusterFS
           Version: 3.5.3
         Component: geo-replication
          Severity: high
          Assignee: bugs at gluster.org
          Reporter: colin.alston at gmail.com
                CC: bugs at gluster.org, gluster-bugs at redhat.com



Description of problem:

Consider the following setup

                 ---[vol1] --<georep>---> [gfs1+gfs2.site2::vol]
                /
[gfs1.site1] ---
                \
                 ---[vol2] --<georep>---> [gfs1+gfs2.site3::vol]

With each cluster set created by peer probing the local hostname of the
corresponding node eg, 
site1: gfs1.site1, gfs2.site1
site2: gfs1.site2, gfs2.site2
site3: gfs1.site3, gfs2.site3

Enter geo-replication, adding the replication to site1 with the full FQDN

gluster volume geo-replication vol1 gfs1.site2::vol

The remote peer will be retrieved without its FQDN as 'gfs2'. This results in
replication attempting to contact its own local peer depending on the search
domain.

More wonderful than this risk to replicating spurious data is that the peer
management tools do not provide a means to back out of this situation without
entire removing all volumes on the sites and starting from scratch. It is not
clear how (or if) it is possible change the hostname in the volume peers, or
the replication. Even if data-loss were acceptable it is impossible to change
between the hostname and FQDN on an already existing peer because it is stored
by IP address instead of the hostname it later interchangeably respects or
discards...

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.