glusterfs.git/geo-replication, branch v3.7.13

geo-rep: Safely handle if unliked GFID not present in data list

2016-06-28T05:31:07+00:00

If unlinked GFID is not present in data list to be synced then
Geo-rep worker was crashing with KeyError. Handled KeyError with
this patch.

BUG: 1348085
Change-Id: I5a1c9ca4473e32606df2e5c7e26c95faf55d44c0
Signed-off-by: Aravinda VK 
Reviewed-on: http://review.gluster.org/14706
(cherry picked from commit 4797ca3778d82a671716d4913c14f285591ae959)
Reviewed-on: http://review.gluster.org/14766
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Kotresh HR 
CentOS-regression: Gluster Build System

geo-rep: Handle stime/xtime set failures

2016-06-27T16:01:54+00:00

While setting stime/xtime, if the file or directory is already
deleted then Geo-rep will crash with ENOENT.

With this patch, Geo-rep will ignores ENOENT since stime/xtime can't
be applied on a deleted file/directory.

Change-Id: I2d90569e51565f81ae53fcb23323e4f47c9e9672
Signed-off-by: Aravinda VK 
BUG: 1345882
Reviewed-on: http://review.gluster.org/14529
(cherry picked from commit 1a348bfaeb9f2a50ec8ce27e5477e9b430c58b3c)
Reviewed-on: http://review.gluster.org/14713
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Kotresh HR

geo-rep: Error message cleanup

2016-06-27T16:01:36+00:00

If ssh returns 127 that means the remote gsyncd path is wrong
or push-pem failed during create. Existing error message was
pointing old documentation.

Change-Id: Ifbbb4a604fc0ae0fd5cb2746df6363bf28cde1e9
BUG: 1347206
Signed-off-by: Aravinda VK 
Reviewed-on: http://review.gluster.org/14673
(cherry picked from commit 3b69e25c0f3cf0b958fbd2b8459712ad21239caa)
Reviewed-on: http://review.gluster.org/14740
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Kotresh HR

glusterd/geo-rep: upgrade path when slave vol uuid involved

2016-06-13T10:36:33+00:00

slave volume uuid is involved in identifying a geo-replication
session.

This patch addresses upgrade path, where existing geo-rep session
is gracefully upgraded to involve slave volume uuid.

Change-Id: Ib7ff5109b161592f24fc86fc7e93a407655fab86
BUG: 1342453
Reviewed-on: http://review.gluster.org/#/c/14425
Signed-off-by: Saravanakumar Arumugam 
Reviewed-on: http://review.gluster.org/14641
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Smoke: Gluster Build System 
Reviewed-by: Aravinda VK

geo-rep: Fix volume stop with geo-rep session

2016-06-06T06:50:50+00:00

Backport of http://review.gluster.org/14636

The slave volume uuid is appended to slave_url
which is saved in 'gsync_slaves' dictionary with
the commit "http://review.gluster.org/13111".
But the gsyncd expects slave_url with out slave
volume uuid otherwise it fails which in turn
fails volume stop with geo-rep. This patch
fixes the same.

Change-Id: I036f4fce43115ff848daebfe1b2c58765cffab5a
BUG: 1342431
Signed-off-by: Kotresh HR 
Reviewed-on: http://review.gluster.org/14637
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Aravinda VK

geo-rep: update peers section in gsyncd conf

2016-06-01T16:32:55+00:00

Problem:
Once Slave volume uuid is involved as part of a geo-rep session, it is
possible to create the same geo-rep session with different (slave)host.

But, it reflects default values for geo-rep configuration values originally
configured for old geo-rep session.
Reason is, slave host is used while saving config options in gsyncd.conf.
With new slave host, it is not possible to retrieve those config values.

Solution:
Remove slave host related information from gsyncd.conf and have only master
volume and slave volume as part of peers section.

Also, during upgrade from old geo-rep session, update peers section to
reflect only master volume and slave volume.

Change-Id: I7debf35a09a28d030b706b0c3e5d82c9b0467d0e
BUG: 1341121
Reviewed-on: http://review.gluster.org/#/c/14558/
Signed-off-by: Saravanakumar Arumugam 
Reviewed-on: http://review.gluster.org/14566
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Aravinda VK

geo-rep: Handle Worker kill gracefully if worker already died

2016-06-01T16:30:36+00:00

If Agent dies for any reason, monitor tries to kill Worker also. But
if worker is also died then kill command raises error ESRCH: No such
process.

[2016-05-23 16:49:33.903965] I [monitor(monitor):326:monitor] Monitor:
    Changelog Agent died, Aborting Worker(/bricks/brick0/master_brick0)
[2016-05-23 16:49:33.904535] E [syncdutils(monitor):276:log_raise_exception]
    : FAIL:
Traceback (most recent call last):
  File "/usr/libexec/glusterfs/python/syncdaemon/syncdutils.py", line 306 in
  twrap
    tf(*aa)
  File "/usr/libexec/glusterfs/python/syncdaemon/monitor.py", line 393, in
  wmon
     slave_host, master)
  File "/usr/libexec/glusterfs/python/syncdaemon/monitor.py", line 327, in
  monitor
     os.kill(cpid, signal.SIGKILL)
     OSError: [Errno 3] No such process

With this patch, monitor will gracefully handle if worker is already died.

Change-Id: I3ae5f816a3a197343b64540cf46f5453167fb660
Signed-off-by: Aravinda VK 
BUG: 1341068
Reviewed-on: http://review.gluster.org/14512
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Kotresh HR 
CentOS-regression: Gluster Build System 
(cherry picked from commit 4f4a94a35a24d781f3f0e584a8cb59c019e50d6f)
Reviewed-on: http://review.gluster.org/14562
Reviewed-by: Saravanakumar Arumugam

glusterd/geo-rep: slave volume uuid to identify a geo-rep session

2016-05-19T06:47:09+00:00

Problem:
Currently, it is possible to create multiple geo-rep session from
the Master host to Slave host(s), where Slave host(s) belonging
to the same volume.

For example:
Consider Master Host M1 having volume tv1 and Slave volume tv2,
which spans across two Slave hosts S1 and S2.
Currently, it is possible to create geo-rep session from
M1(tv1) to S1(tv2) as well as from M1(tv1) to S2(tv2).

When the Slave Host is alone modified, it is identified as a new geo-rep
session (as slave host and slave volume together are identifying
Slave side).

Also, it is possible to create both root and non-root geo-rep session between
same Master volume and Slave volume. This should also be avoided.

Solution:
This multiple geo-rep session creation must be avoided and
in order to avoid, use Slave volume uuid to identify a Slave.
This way, we can identify whether a session is already created for
the same Slave volume and avoid creating again (using different host).

When the session creation is forced in the above scenario, rename
the existing geo-rep session directory with new Slave Host mentioned.

Change-Id: I9239759cbc0d15dad63c48b8cf62950bb687c7c8
BUG: 1335728
Signed-off-by: Saravanakumar Arumugam 
Signed-off-by: Aravinda VK 
Reviewed-on: http://review.gluster.org/13111
Reviewed-by: Kotresh HR 
Tested-by: Kotresh HR 
Reviewed-by: Atin Mukherjee 
 (cherry picked from commit a9128cda34b1f696b717ba09fa0ac5a929be8969)
Reviewed-on: http://review.gluster.org/14322
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

geo-rep: Fix Entry Creation issue with non root UID/GID

2016-03-09T11:02:36+00:00

During entry_ops RENAME Geo-rep sends stat info along with the
recorded info from Changelog. In Slave side if Source file exists
Geo-rep renames to Target file by calling os.rename. If source file
does not exists, it tries to create Target file directly using available
stat info from Master. If UID and GID are different in Master for that
file then stat info will have different UID/GID during Create. Geo-rep
gets EACCES when it tries to create a new entry using gfid-access with
different UID/GID.

With this patch, Entry creation with different UID/GID is split into two
operations. Create Entry with UID:0 and GID:0 and then set UID/GID.

Change-Id: I4987e3a205d8513c06fa66198cde145a87003a01
BUG: 1312762
Signed-off-by: Aravinda VK 
Reviewed-on:http://review.gluster.org/13542
Reviewed-on: http://review.gluster.org/13643
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Kotresh HR

geo-rep: hard-link rename issues on changelog replay

2016-03-09T08:26:27+00:00

Problem:
LINK + RENAME changelog when replayed after worker restart causes stale
hard-links to persist since VFS returns success for RENAME if hard-links
point to same inode.

Solution:
Worker detects RENAME being issued on hard-links to the same inode and
unlinks the source file-name. Conditionally rename by verifying that the
source gfid matches with the on-disk gfid on the slave.

Change-Id: I3ff1c30ef79e77503c8b246d46dab8ac3059ccf2
BUG: 1296175
Reviewed-on: http://review.gluster.org/13189
Signed-off-by: Milind Changire 
Reviewed-on: http://review.gluster.org/13638
Smoke: Gluster Build System 
Tested-by: Aravinda VK 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Aravinda VK