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...