Bug 992939 - Dist-geo-rep: "volume stop" CLI should not throw error message when the geo-replication session is stopped
Dist-geo-rep: "volume stop" CLI should not throw error message when the geo-r...
Status: CLOSED DUPLICATE of bug 1002822
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: geo-replication (Show other bugs)
2.1
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Kotresh HR
Sudhir D
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-05 05:01 EDT by M S Vishwanath Bhat
Modified: 2016-05-31 21:56 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-05-20 01:33:58 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description M S Vishwanath Bhat 2013-08-05 05:01:39 EDT
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 01:33:58 EDT
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 ***

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