Hide Forgot
+++ This bug was initially created as a clone of Bug #1230646 +++ Description of problem: When geo-replcation session is created with root user, we are not able to create snapshots for the master volume. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create a geo-replication session between two volumes with root user using RHGS-C. The geo-replication session status is CREATED. 2. Try to create snapshot for master volume 3. Actual results: Snippet from log file shows below error [2015-06-11 06:57:54.688548] E [MSGID: 106031] [glusterd-snapshot.c:5102:glusterd_do_snap_vol] 0-management: Failed to copy geo-rep config and status files for volume vol1 [2015-06-11 06:57:54.688636] W [MSGID: 106071] [glusterd-snapshot.c:2927:glusterd_snap_volume_remove] 0-management: Failed to remove volume 361b1a1e6a8e4a2ab76f49f1dfe9a5a9 from store [2015-06-11 06:57:54.688691] W [MSGID: 106030] [glusterd-snapshot.c:6616:glusterd_snapshot_create_commit] 0-management: taking the snapshot of the volume vol1 failed [2015-06-11 06:57:54.688985] E [MSGID: 106030] [glusterd-snapshot.c:7969:glusterd_snapshot] 0-management: Failed to create snapshot [2015-06-11 06:57:54.689014] W [MSGID: 106123] [glusterd-mgmt.c:242:gd_mgmt_v3_commit_fn] 0-management: Snapshot Commit Failed [2015-06-11 06:57:54.689032] E [MSGID: 106123] [glusterd-mgmt.c:1240:glusterd_mgmt_v3_commit] 0-management: Commit failed for operation Snapshot on local node [2015-06-11 06:57:54.689050] E [MSGID: 106123] [glusterd-mgmt.c:2112:glusterd_mgmt_v3_initiate_snap_phases] 0-management: Commit Op Failed [2015-06-11 06:57:54.765903] I [MSGID: 106057] [glusterd-snapshot.c:6069:glusterd_do_snap_cleanup] 0-management: Snapshot (demo_GMT-2015.06.11-06.57.52) does not exist [Invalid argument] [2015-06-11 06:58:06.378298] I [glusterd-geo-rep.c:2022:glusterd_get_statefile_name] 0-: Using passed config template(/var/lib/glusterd/geo-replication/vol1_10.70.42.58_vol2/gsyncd.conf). [2015-06-11 06:57:54.688538] E [MSGID: 106029] [glusterd-snapshot.c:533:glusterd_copy_geo_rep_session_files] 0-management: Session files not present in /var/lib/glusterd/geo-replication/vol1_root@10.70.42.58_vol2 [No such file or directory] [2015-06-11 06:57:54.688544] E [MSGID: 106029] [glusterd-snapshot.c:741:glusterd_copy_geo_rep_files] 0-management: Failed to copy files related to session vol1_root@10.70.42.58_vol2 [2015-06-11 06:58:54.688948] E [glusterd-syncop.c:1070:_gd_syncop_commit_op_cbk] 0-management: Failed to aggregate response from node/brick Expected results: Snapshot creation should be successful.
REVIEW: http://review.gluster.org/11233 (glusterd: Fix snapshot of a volume with geo-rep) posted (#1) for review on master by Kotresh HR (khiremat@redhat.com)
REVIEW: http://review.gluster.org/11233 (glusterd: Fix snapshot of a volume with geo-rep) posted (#2) for review on master by Kotresh HR (khiremat@redhat.com)
COMMIT: http://review.gluster.org/11233 committed in master by Krishnan Parthasarathi (kparthas@redhat.com) ------ commit daf22a3b59f42c897f345dab74c3852ddf9bddef Author: Kotresh HR <khiremat@redhat.com> Date: Mon Jun 15 17:20:46 2015 +0530 glusterd: Fix snapshot of a volume with geo-rep Problem: Snapshot fails for a volume configured with geo-rep if geo-rep is created with root user with the following syntax. gluster vol geo-rep <master_vol> root@<slave_host>::<slave_vol> It works fine if created with following syntax. gluster vol geo-rep <master_vol> <slave_host>::<slave_vol> Cause: Geo-rep maintains persistent dictionary of slave associated with master volume. The dictionary saves the slave info along with 'root@' as sent from cli. Snapshot while constructing the working dir path to copy configuration files, constructs using this dictionary. But the actual working dir is created with out considering 'root@'. Hence the issue. Fix: Fix is done at two layers. 1. Parse and negelect 'root@' in cli itself. 2. For existing geo-rep sessions and upgrade scenarios, parse and neglect 'root@' in snapshot code as well. Change-Id: If4e04f7f776ef71df4dd1e7e053ef75db98762b2 BUG: 1231789 Signed-off-by: Kotresh HR <khiremat@redhat.com> Reviewed-on: http://review.gluster.org/11233 Reviewed-by: Avra Sengupta <asengupt@redhat.com> Tested-by: Gluster Build System <jenkins@build.gluster.com> Tested-by: NetBSD Build System <jenkins@build.gluster.org> Reviewed-by: Krishnan Parthasarathi <kparthas@redhat.com>
Fix for this BZ is already present in a GlusterFS release. You can find clone of this BZ, fixed in a GlusterFS release and closed. Hence closing this mainline BZ as well.
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.8.0, please open a new bug report. glusterfs-3.8.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution. [1] http://blog.gluster.org/2016/06/glusterfs-3-8-released/ [2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user