Bug 1344605

Description of problem:
=======================

Known ways to add a brick from new node is to by following steps:

1. gsec create
2. create push-pem force

But with the recent validation check, the create push-pem fails complaining that the geo-rep session exists. And hence gsyncd on new node doesn't start.

If the master volume and slave volume remains same, and also if user and host remains same, then the force should not fail.

[root@dhcp37-88 ~]# gluster system:: execute gsec_create 
Common secret pub file present at /var/lib/glusterd/geo-replication/common_secret.pem.pub
[root@dhcp37-88 ~]# #gluster volume geo-replication master_nr rahul.37.52::slave_nr create push-pem
[root@dhcp37-88 ~]# gluster volume geo-replication status
 
MASTER NODE    MASTER VOL    MASTER BRICK      SLAVE USER    SLAVE                       SLAVE NODE      STATUS     CRAWL STATUS       LAST_SYNCED                  
---------------------------------------------------------------------------------------------------------------------------------------------------------
10.70.37.88    vol24         /rhs/brick1/b1    root          ssh://10.70.37.52::vol25    10.70.37.190    Active     Changelog Crawl    2016-06-05 07:31:49          
10.70.37.88    vol24         /rhs/brick2/b3    root          ssh://10.70.37.52::vol25    10.70.37.190    Active     Changelog Crawl    2016-06-05 07:31:49          
10.70.37.43    vol24         /rhs/brick1/b2    root          ssh://10.70.37.52::vol25    10.70.37.52     Passive    N/A                N/A                          
10.70.37.43    vol24         /rhs/brick2/b4    root          ssh://10.70.37.52::vol25    10.70.37.52     Passive    N/A                N/A                          
[root@dhcp37-88 ~]# 
[root@dhcp37-88 ~]# gluster volume geo-replication vol24 10.70.37.52::vol25 create push-pem force
Geo -replication session between vol24 and 10.70.37.52::vol25 is still active. Please stop the session and retry.
geo-replication command failed
[root@dhcp37-88 ~]#



Version-Release number of selected component (if applicable):
=============================================================


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


Steps to Reproduce:
===================
1. Have existing geo-rep session
2. Add new node on Master cluster
3. gsec_create
4. create push-pem force with same master,slave,user and hostname

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

create push-pem fails and gsync doesn't get started

--- Additional comment from Rahul Hinduja on 2016-06-06 03:43:27 EDT ---

Work around available: Use stop force before create push-pem force

* gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL
stop force
* gluster volume geo-replication MASTER_VOL SLAVE_HOST::SLAVE_VOL
create push-pem force

--- Additional comment from Vijay Bellur on 2016-06-10 03:20:22 EDT ---

COMMIT: http://review.gluster.org/14653 committed in master by Aravinda VK (avishwan) 
------
commit c62493efadbcf5085bbd65a409eed9391301c154
Author: Saravanakumar Arumugam <sarumuga>
Date:   Mon Jun 6 14:44:35 2016 +0530

    glusterd/geo-rep: Avoid started status check if same host
    
    After carrying out add-brick, session creation is carried out
    again, to involve new brick in the session. This needs to be done,
    even if the session is in Started state.
    
    While involving slave uuid as part of a session, User is warned
    if session is in Started state. This check needs to be avoided
    if it is same slave host and session creation needs to be proceeded.
    
    Change-Id: Ic73edd5bd9e3ee55da96f5aceec0bafa14d3f3dd
    BUG: 1342979
    Signed-off-by: Saravanakumar Arumugam <sarumuga>
    Reviewed-on: http://review.gluster.org/14653
    CentOS-regression: Gluster Build System <jenkins.com>
    Smoke: Gluster Build System <jenkins.com>
    NetBSD-regression: NetBSD Build System <jenkins.org>
    Reviewed-by: Aravinda VK <avishwan>