Bug 1340383 - [geo-rep]: If the session is renamed, geo-rep configuration are not retained
Summary: [geo-rep]: If the session is renamed, geo-rep configuration are not retained
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat Storage
Component: geo-replication
Version: rhgs-3.1
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
: RHGS 3.1.3
Assignee: Saravanakumar
QA Contact: Rahul Hinduja
URL:
Whiteboard:
Depends On:
Blocks: 1311817 1340853 1341108 1341121
TreeView+ depends on / blocked
 
Reported: 2016-05-27 08:52 UTC by Rahul Hinduja
Modified: 2016-06-23 05:24 UTC (History)
4 users (show)

Fixed In Version: glusterfs-3.7.9-7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1340853 (view as bug list)
Environment:
Last Closed: 2016-06-23 05:24:47 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:1240 0 normal SHIPPED_LIVE Red Hat Gluster Storage 3.1 Update 3 2016-06-23 08:51:28 UTC

Description Rahul Hinduja 2016-05-27 08:52:00 UTC
Description of problem:
=======================

With the recent changes, we support to rename the existing geo-rep session from one slave hot to another slave host. Expected is to rename only the session and retain all the configuration/status as of the previous session. 

But the older configurations are not retained which passively breaks the geo-rep functionality for this use case. 

Existing session between: baloo 10.70.37.88::bagheera

[root@dhcp37-162 ~]# gluster volume geo-replication baloo 10.70.37.88::bagheera config change_detector
xsync
[root@dhcp37-162 ~]# gluster volume geo-replication baloo 10.70.37.88::bagheera config ignore_deletes
true
[root@dhcp37-162 ~]# gluster volume geo-replication baloo 10.70.37.88::bagheera config use_meta_volume
true
[root@dhcp37-162 ~]#

New Session between: baloo 10.70.37.43::bagheera 

[root@dhcp37-162 ~]# gluster volume geo-replication baloo 10.70.37.43::bagheera config use_meta_volume
[root@dhcp37-162 ~]# gluster volume geo-replication baloo 10.70.37.43::bagheera config ignore_deletes
false
[root@dhcp37-162 ~]# gluster volume geo-replication baloo 10.70.37.43::bagheera config change_detector
changelog
[root@dhcp37-162 ~]# 



Version-Release number of selected component (if applicable):
=============================================================
glusterfs-3.7.9-6.el7rhgs.x86_64


How reproducible:
=================

Always


Steps to Reproduce:
===================
1. Create georep session between master, slavehost1 and slave
2. Update configs for this session
3. Stop existing session
4. Recreate session between master, slavehost2 and slave
5. Start the session
6. Verify for the configs setup at step 2

Actual results:
===============

Config options are reset


Expected results:
=================

Since it is a rename of a session and not the new session, all config options should be retained

Comment 7 Saravanakumar 2016-05-30 09:08:08 UTC
RCA:
In gsyncd.conf, "peers" sections contains  old Slave Host details.

example:
peers gluster%3A%2F%2F127.0.0.1%3Atv1 ssh%3A2F%2Froot%40192.168.122.186%3Agluster%3A%2F%2F127.0.0.1%3Atv2

Where, 192.168.122.186 is old slave host IP address.

Once the geo-rep session is renamed, old host details are no longer valid.
So, with new host, it is NOT possible to get config details.

Solution:
Remove old host details from peers section.

Use only master volume and slave volume as part of peers section and remove slave host detail.

Comment 8 Atin Mukherjee 2016-05-31 04:19:10 UTC
Upstream patch http://review.gluster.org/14558 up for review.

Comment 9 Aravinda VK 2016-05-31 10:21:42 UTC
Downstream patch: https://code.engineering.redhat.com/gerrit/#/c/75488/

Comment 11 Rahul Hinduja 2016-06-01 14:50:03 UTC
Verified with build: glusterfs-3.7.9-7 . Configurations are retained if the existing geo-rep session is renamed. 

Moving this bug to verified state.

Comment 14 errata-xmlrpc 2016-06-23 05:24:47 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2016:1240


Note You need to log in before you can comment on or make changes to this bug.