Bug 1203135
| Summary: | geo-replication spuriously ignores FQDN | ||
|---|---|---|---|
| Product: | [Community] GlusterFS | Reporter: | Colin Alston <colin.alston> |
| Component: | geo-replication | Assignee: | Aravinda VK <avishwan> |
| Status: | CLOSED EOL | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.5.3 | CC: | bugs, mselvaga |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-06-17 16:24:25 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This bug is getting closed because the 3.5 is marked End-Of-Life. There will be no further updates to this version. Please open a new bug against a version that still receives bugfixes if you are still facing this issue in a more current release. |
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...