Once glusterfs is upgraded (which involves geo-replication slave volume uuid as part of vol info), if geo-replication status command is run, it creates an empty monitor.status file (without restarting glusterd daemon) Now, once the glusterd is restarted after the above step, glusterd updates the monitor.status file with "Started" state. This "Started" state gets reflected if you run "gluster volume geo-replication MasterVolume Slavehost::Slavevolume status" command. Solution is to avoid updating monitor.status file(with "Started" status) if monitor.status is empty.
REVIEW: http://review.gluster.org/14830 (glusterd/geo-rep: Handle empty monitor.status during upgrade) posted (#1) for review on master by Saravanakumar Arumugam (sarumuga)
REVIEW: http://review.gluster.org/14830 (glusterd/geo-rep: Handle empty monitor.status during upgrade) posted (#2) for review on master by Saravanakumar Arumugam (sarumuga)
COMMIT: http://review.gluster.org/14830 committed in master by Jeff Darcy (jdarcy) ------ commit f938b3a26ffab9482d5f910ee76d2bb2b370517f Author: Saravanakumar Arumugam <sarumuga> Date: Wed Jun 29 15:36:06 2016 +0530 glusterd/geo-rep: Handle empty monitor.status during upgrade Problem: Consider geo-replication is in Stopped state. Following which, glusterfs is upgraded (where monitor.status is the new status file). Now, When geo-replication status command is run, empty monitor status file gets created. Now, if glusterd is restarted, it reads empty monitor status and starts geo-replication session. This is incorrect as session was in Stopped state earlier. Solution: If monitor status is empty, error out and avoid starting geo-replication session. Note: if monitor status is empty, geo-rep session is displayed as Stopped state. Change-Id: Ifb3db896e5ed92b927764cf1163503765cb08bb4 BUG: 1351071 Signed-off-by: Saravanakumar Arumugam <sarumuga> Reviewed-on: http://review.gluster.org/14830 Smoke: Gluster Build System <jenkins.org> CentOS-regression: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> Reviewed-by: Jeff Darcy <jdarcy>