Bug 996999

Summary: Dist-geo-rep : geo-rep config special-sync-mode takes any value successfully and make status to faulty.
Product: [Red Hat Storage] Red Hat Gluster Storage Reporter: Vijaykumar Koppad <vkoppad>
Component: geo-replicationAssignee: Avra Sengupta <asengupt>
Status: CLOSED ERRATA QA Contact: Vijaykumar Koppad <vkoppad>
Severity: medium Docs Contact:
Priority: urgent    
Version: 2.1CC: aavati, amarts, asengupt, bbandari, csaba, rhs-bugs, sdharane
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: glusterfs-3.4.0.22rhs-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 998962 (view as bug list) Environment:
Last Closed: 2013-09-23 22:38:51 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:
Bug Depends On:    
Bug Blocks: 998962    

Description Vijaykumar Koppad 2013-08-14 13:03:25 UTC 
Description of problem: If the geo-rep config special-sync-mode is set to wrong value, it takes it successfully and makes the geo-rep status to faulty. 

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
[root@shaktiman ~]# gluster v geo master 10.70.43.23::imaster config special-sync-mode sDGs
geo-replication config updated successfully

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

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


How reproducible:happens every time 


Steps to Reproduce:
1.Create and start a geo-rep relationship between master and slave. 
2.set the config special-sync-mode to some random value
3.check the geo-rep status 

Actual results: special-sync-mode succeeds for the wrong value and makes the geo-rep status faulty 


Expected results: First of all it should proper error message, and also it should never take the status to faulty. 


Additional info:
Comment 2 Amar Tumballi 2013-08-14 13:39:31 UTC 
Avra/Venky,

We need a fix to handle this option more carefully, and notify user that its not valid. At least 'gsyncd' process should not get into the recursive failure mode.

Lets try to get it addressed early.
Comment 3 Venky Shankar 2013-08-19 02:53:04 UTC 
This happens as the config value is used to instantiate a class that has the config string as the class name. Checking this string for validity in gsyncd (worker) might be too late as monitor tracks the state of the worker process which in this case errors out due to an invalid class name.
Comment 4 Amar Tumballi 2013-08-21 06:20:06 UTC 
https://code.engineering.redhat.com/gerrit/#/c/11610/
Comment 5 Vijaykumar Koppad 2013-08-26 06:32:05 UTC 
verified on glusterfs-3.4.0.22rhs-2.el6rhs.x86_64
Comment 6 Scott Haines 2013-09-23 22:38:51 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.

http://rhn.redhat.com/errata/RHBA-2013-1262.html
Comment 7 Scott Haines 2013-09-23 22:41:31 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.

http://rhn.redhat.com/errata/RHBA-2013-1262.html