+++ 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):
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
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 /email@example.com_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 firstname.lastname@example.org_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
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 (email@example.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 (firstname.lastname@example.org)
COMMIT: http://review.gluster.org/11233 committed in master by Krishnan Parthasarathi (email@example.com)
Author: Kotresh HR <firstname.lastname@example.org>
Date: Mon Jun 15 17:20:46 2015 +0530
glusterd: Fix snapshot of a volume with geo-rep
Snapshot fails for a volume configured with geo-rep
if geo-rep is created with root user with the following
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>
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 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.
Signed-off-by: Kotresh HR <email@example.com>
Reviewed-by: Avra Sengupta <firstname.lastname@example.org>
Tested-by: Gluster Build System <email@example.com>
Tested-by: NetBSD Build System <firstname.lastname@example.org>
Reviewed-by: Krishnan Parthasarathi <email@example.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 , packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist  and the update infrastructure for your distribution.