Bug 1027142 - Dist-geo-rep : After remove brick commit it should stop the gsyncd running on the removed node
Dist-geo-rep : After remove brick commit it should stop the gsyncd running on...
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: geo-replication (Show other bugs)
x86_64 Linux
medium Severity high
: ---
: RHGS 3.1.0
Assigned To: Kotresh HR
Rahul Hinduja
Depends On:
Blocks: 1202842 1223636
  Show dependency treegraph
Reported: 2013-11-06 04:23 EST by Vijaykumar Koppad
Modified: 2015-07-29 00:29 EDT (History)
6 users (show)

See Also:
Fixed In Version: glusterfs-3.7.0-2.el6rhs
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-07-29 00:29:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:1495 normal SHIPPED_LIVE Important: Red Hat Gluster Storage 3.1 update 2015-07-29 04:26:26 EDT

  None (edit)
Description Vijaykumar Koppad 2013-11-06 04:23:25 EST
Description of problem: After remove brick commit it should stop the gsyncd running on the removed node. In geo-rep, there will one monitor process per node and one worker process per brick. After remove brick, the worker process corresponding to removed brick should be stopped

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

How reproducible:Happens everytime 

Steps to Reproduce:
1.create and start a geo-rep relationship between master and slave 
2.add a new node to the cluser and add brick to the volume.
3.do gsec_create, create push-pem force and start force. 
4. remove the added brick. 

Actual results: geo-rep fails to stop the worker process corresponding to removed brick

Expected results: It should stop the gsyncd process, other wise it becomes stale process and it might introduce new problems.

Additional info:
Comment 7 Rahul Hinduja 2015-06-09 07:08:30 EDT
Verified with build: glusterfs-3.7.1-1.el6rhs.x86_64

As mentioned in the comment 3, the geo-rep session should be stopped before commit which is documented in the guide as well. Doing so, will kill all the gsyncd process and hence wont hit the bug mentioned in the description. 

Verified the documented steps and no gsyncd process was running on the removed node. Moving the bug to verified state.
Comment 9 errata-xmlrpc 2015-07-29 00:29:30 EDT
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.


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