Description of problem: ======================= If the slave volume is part of any geo-rep session, then another attempt to use the same slave volume should be restricted. This is currently allowed if the session is already established as root and another attempt is made using user. In this case master volume info file is appended with both the slave entries one with slavehostname and another with <user>@slavehostname. Now, if any one of the geo-rep session is deleted for example root session. All the session gets deleted. Version-Release number of selected component (if applicable): ============================================================= glusterfs-3.7.1-14.el7rhgs.x86_64 How reproducible: ================= Always Steps to Reproduce: =================== 1. Create and start geo-rep session between master and slave {root} 2. Create another geo-rep session between same master ans slave using same slave host but with user account {non-root} Actual results: =============== Able to create the session Expected results: ================= If slave is part of any geo-rep session the subsequent attempt to create different geo-rep session should fail
Patch sent to Upstream http://review.gluster.org/#/c/13111/
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Downstream patch sent https://code.engineering.redhat.com/gerrit/#/c/74262/
Verified with the build: glusterfs-geo-replication-3.7.9-6.el7rhgs.x86_64 glusterfs-3.7.9-6.el7rhgs.x86_64 With the latest changes, existing geo-rep session between master and slave can be converted to secure(non-root) or different users. But at any given point in time, only one session between master and slave can be active and hence the existing geo-rep session needs to be stoped before creating with other user. Verified the above scenario, which works. Moving the bug to verified state.
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. https://access.redhat.com/errata/RHBA-2016:1240