Description of problem: Earlier, once the checkpoint was set it was able to reset or unset using command "gluster v geo <master> <slave-url> config \!checkpoint" Version-Release number of selected component (if applicable): glusterfs-3.4.0.37rhs-1 How reproducible: Happens everytime. Steps to Reproduce: 1.Create and start a geo-rep relationship between master and slave. 2.set config checkpoint 3.try to unset it using the command "gluster v geo <master> <slave-url> config \!checkpoint" Actual results: It doesn't have any effect. Expected results: should be able to unset with that command. Additional info:
https://code.engineering.redhat.com/gerrit/15088
I tried it in the build glusterfs-3.4.0.39rhs, it doesn't work.
Since we made the change not to restart when checkpoint changed. Checkpoint change will reflect in when checkpoint loop reads the value next time(a few seconds delay)
Please try the following: 1. Set checkpoint 2. Check the config values(checkpoint) "gluster v geo <master> <slave-url> config 3. Reset the checkpoint "gluster v geo <master> <slave-url> config \!checkpoint" 4. Check the config values using "gluster v geo <master> <slave-url> config Amar, in your patch we may need to remove "checkpoint_target" along with the "checkpoint_completed"
verified on glusterfs-3.4.0.43rhs-1. Now it can be reset using the command "gluster v geo <master> <slave-url> config \!checkpoint"
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-1769.html