Bug 1327494

Summary: [Feedback in SME-Storage] Geo-replication: Information in Section 14.1 is contradicting info in Section 14.3
Product: Red Hat Gluster Storage Reporter: Divya <divya>
Component: doc-Administration_GuideAssignee: Divya <divya>
doc-Administration_Guide sub component: Default QA Contact: Rahul Hinduja <rhinduja>
Status: CLOSED CURRENTRELEASE Docs Contact:
Severity: unspecified    
Priority: unspecified CC: ahatfiel, asriram, asrivast, avishwan, mhideo, nlevinki, rcyriac, rhinduja, rhs-bugs, rwheeler, storage-doc
Version: rhgs-3.1Keywords: Documentation, ZStream
Target Milestone: ---   
Target Release: RHGS 3.1.3   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-06-29 14:22:24 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:
Bug Depends On:    
Bug Blocks: 1311847    

Description Divya 2016-04-15 08:52:05 UTC
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.


<<<<

Comment 3 Divya 2016-05-27 11:37:49 UTC
(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!

Comment 5 Divya 2016-06-02 11:07:33 UTC
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

Comment 6 Rahul Hinduja 2016-06-13 15:47:58 UTC
Document changes for only mentioning remote-host looks good to me. Moving this to verified state.