Bug 992939

Summary: Dist-geo-rep: "volume stop" CLI should not throw error message when the geo-replication session is stopped
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: M S Vishwanath Bhat <vbhat>
Component: geo-replicationAssignee: Kotresh HR <khiremat>
Status: CLOSED DUPLICATE QA Contact: Sudhir D <sdharane>
Severity: low Docs Contact:
Priority: medium    
Version: 2.1CC: aavati, csaba, khiremat, mzywusko, nsathyan, rhs-bugs, rwheeler, vagarwal
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-05-20 05:33:58 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:

Description M S Vishwanath Bhat 2013-08-05 09:01:39 UTC
Description of problem:
If the geo-replication session is active, then the volume stop with throw an warning/error message saying the geo-rep session is active and use force if you still want to stop the volume. This message should not be shown if the geo-rep session is stopped by geo-rep stop cli. Since the session is not active, the volume stop should also work just fine.

Version-Release number of selected component (if applicable):
glusterfs-3.4.0.14rhs-1.el6rhs.x86_64

How reproducible:
Many times in my setup.

Steps to Reproduce:
1. Create and start a geo-rep session between master and slave.
2. Now stop the session using geo-rep stop CLI.
3. Try to stop volume using the command volume stop.

Actual results:

[root@typhoon ~]# gluster v stop master --mode=script
volume stop: master: failed: geo-replication sessions are active for the volume 'master'.
Use 'volume geo-replication status' command for more info. Use 'force' option to ignore and stop the volume.

But the geo-rep session is not really active. It's been stopped.

[root@typhoon ~]# gluster v geo master status
NODE                       MASTER    SLAVE                  HEALTH     UPTIME       
------------------------------------------------------------------------------------
typhoon.blr.redhat.com     master    ssh://falcon::slave    Stopped    N/A          
mustang.blr.redhat.com     master    ssh://falcon::slave    Stopped    N/A          
harrier.blr.redhat.com     master    ssh://falcon::slave    Stopped    N/A          
spitfire.blr.redhat.com    master    ssh://falcon::slave    Stopped    N/A          

Expected results:
volume stop should succeed when the geo-rep session is stopped.

Additional info:

logs from the glusterd

~
[2013-08-05 08:41:21.865044] W [glusterd-volume-ops.c:1037:glusterd_op_stage_stop_volume] 0-management: geo-replication sessions activefor the volume master 
[2013-08-05 08:41:21.865150] E [glusterd-syncop.c:872:gd_stage_op_phase] 0-management: Staging of operation 'Volume Stop' failed on localhost : geo-replication sessions are active for the volume 'master'.
Use 'volume geo-replication status' command for more info. Use 'force' option to ignore and stop the volume.
[2013-08-05 08:41:34.644440] I [glusterd-geo-rep.c:274:__glusterd_handle_gsync_set] 0-management: slave not found, whilehandling geo-replication options
[2013-08-05 08:41:59.465206] W [glusterd-volume-ops.c:1037:glusterd_op_stage_stop_volume] 0-management: geo-replication sessions activefor the volume master 
[2013-08-05 08:41:59.465443] E [glusterd-syncop.c:872:gd_stage_op_phase] 0-management: Staging of operation 'Volume Stop' failed on localhost : geo-replication sessions are active for the volume 'master'.
Use 'volume geo-replication status' command for more info. Use 'force' option to ignore and stop the volume.
[2013-08-05 08:56:00.419505] I [glusterd-geo-rep.c:274:__glusterd_handle_gsync_set] 0-management: slave not found, whilehandling geo-replication options


I also ran 'ps -aef | grep gluster' in all the master nodes to check if there is any geo-rep related processes running. But there weren't any.

Comment 2 Kotresh HR 2014-05-20 05:33:58 UTC
This is fixed as part of Bug 1002822 and is ON_QA
http://review.gluster.org/#/c/6821/
Hence marking as duplicate.

*** This bug has been marked as a duplicate of bug 1002822 ***