Hide Forgot
Creating the bug based on the following email sent to sme-storage: >>>> From: "Andrew Hatfield" <andrew.hatfield> To: "sme-storage" <sme-storage> Sent: Friday, April 15, 2016 9:44:45 AM Subject: Re: Geo-Replication in RHGS then in 14.3.3 Pre-requisites we contradict what I think 14.1 says Slave node must not be a peer of the any of the nodes of the Master trusted storage pool. ---- On Fri, Apr 15, 2016 at 2:13 PM, Andrew Hatfield <andrew.hatfield> wrote: We used to allow local geo-replication in RHGS and then dropped it, forcing it to be another TSP. 14.1 at https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/chap-Managing_Geo-replication.html now seems to imply we can do a local geo-replication again. is this correct? Geo-replication provides a distributed, continuous, asynchronous, and incremental replication service from one site to another over Local Area Networks (LANs), Wide Area Networks (WANs), and the Internet. Geo-replication uses a master–slave model, where replication and mirroring occurs between the following partners: Master – a Red Hat Gluster Storage volume. Slave – a Red Hat Gluster Storage volume. A slave volume can be either a local volume, such as localhost::volname, or a volume on a remote host, such as remote-host::volname. <<<<
(In reply to Divya from comment #0) > Creating the bug based on the following email sent to sme-storage: > > >>>> > > From: "Andrew Hatfield" <andrew.hatfield> > To: "sme-storage" <sme-storage> > Sent: Friday, April 15, 2016 9:44:45 AM > Subject: Re: Geo-Replication in RHGS > > then in 14.3.3 Pre-requisites we contradict what I think 14.1 says > > Slave node must not be a peer of the any of the nodes of the Master trusted > storage pool. > > ---- > > On Fri, Apr 15, 2016 at 2:13 PM, Andrew Hatfield > <andrew.hatfield> wrote: > > We used to allow local geo-replication in RHGS and then dropped it, > forcing it to be another TSP. > > 14.1 at > https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/ > Administration_Guide/chap-Managing_Geo-replication.html now seems to imply > we can do a local geo-replication again. > > is this correct? > > > > Geo-replication provides a distributed, continuous, asynchronous, and > incremental replication service from one site to another over Local Area > Networks (LANs), Wide Area Networks (WANs), and the Internet. > Geo-replication uses a master–slave model, where replication and > mirroring occurs between the following partners: > > Master – a Red Hat Gluster Storage volume. > Slave – a Red Hat Gluster Storage volume. A slave volume can be > either a local volume, such as localhost::volname, or a volume on a remote > host, such as remote-host::volname. > > > <<<< Aravinda, You had replied as the following to this query: >>>> On 04/15/2016 02:26 PM, Aravinda wrote: > Hi, > > Old Geo-replication was supporting Remote Gluster Volumes mounted in local node and syncing. This feature is disabled. > > But as you mention we have conflicting statements in doc. There is a open bug about allowing Geo-rep when Slave volume is in same trusted pool(BZ 1116168) > > We will analyze the possibility of enabling this from Engineering else we should open a doc bug to fix this. > regards > Aravinda <<<< Wanted too know if this issue is fixed by the engineering or should I go ahead and update the doc? Thanks!
Based on my discussion with Aravinda, the code is yet to be fixed. Hence, I have updated the "14.1. About Geo-replication" section based on the bug description. Link to the latest doc: http://jenkinscat.gsslab.pnq.redhat.com:8080/view/Gluster/job/doc-Red_Hat_Gluster_Storage-3.1.3-Administration_Guide%20%28html-single%29/lastBuild/artifact/tmp/en-US/html-single/index.html#About_Geo-replication
Document changes for only mentioning remote-host looks good to me. Moving this to verified state.