glusterfs.git, branch v5.9

doc: Added release 5.9 notes

2019-08-06T11:27:16+00:00

Fixes: bz#1737313

Change-Id: Icc44f0d1b33de628ba5c1b0672ed56791d281dcf
Signed-off-by: hari gowtham

geo-rep: Fix mount broker setup issue

2019-08-06T07:02:00+00:00

Even the use builtin 'type' command as in patch [1]
causes issues if argument in question is not part of PATH
environment variable for that user. This patch fixes the
same by doing source /etc/profile. This was already being
used in another part of script.

[1] https://review.gluster.org/23089

Backport of:
 > Patch: https://review.gluster.org/23136/
 > Change-Id: Iceb78835967ec6a4350983eec9af28398410c002
 > BUG: 1734738
 > Signed-off-by: Kotresh HR 

Change-Id: Iceb78835967ec6a4350983eec9af28398410c002
fixes: bz#1737716
Signed-off-by: Kotresh HR

gfapi: Fix deadlock while processing upcall

2019-08-02T10:05:52+00:00

As mentioned in bug1733166, there could be potential deadlock
while processing upcalls depending on how each xlator choose
to act on it. The right way of fixing such issues
is to change rpc callback communication process.
- https://github.com/gluster/glusterfs/issues/697

Till then, making changes in gfapi layer to avoid any I/O
processing.

This is backport of below mainline patch
> https://review.gluster.org/#/c/glusterfs/+/23108/
> bz#1733166

Change-Id: I2079e95339e5d761d5060707f4555cfacab95c83
fixes: bz#1736342
Signed-off-by: Soumya Koduri

geo-rep: Fix mount broker setup issue

2019-07-29T08:54:36+00:00

The patch [1] added validation in gverify.sh to check if the gluster
binary exists on slave by executing gluster directly on slave.  But for
non-root users, even though gluster binary is present, path is not
found when executed via ssh. Hence validate the gluster binary using
bash builtin 'type' command.

[1] https://review.gluster.org/19224

Backport of:
 > Patch: https://review.gluster.org/23089/
 > Change-Id: I93ca62c0c5b1e16263e586ddbbca8407d60ca126
 > BUG: 1731920
 > Signed-off-by: Kotresh HR 
(cherry picked from commit 2aa731a259ea457c07494e3c3edf6d5f7c02fe77)

Change-Id: I93ca62c0c5b1e16263e586ddbbca8407d60ca126
fixes: bz#1733881
Signed-off-by: Kotresh HR

doc: Added release 5.8 notes

2019-07-18T12:25:54+00:00

Fixes: bz#1731014

Change-Id: I4b8c079865a0193f0a3c4665230ca6c50a223dea
Signed-off-by: hari gowtham

glusterd: add GF_TRANSPORT_BOTH_TCP_RDMA in glusterd_get_gfproxy_client_volfile

2019-07-18T06:26:14+00:00

... with out which volume creation fails with "volume create: : failed:
Failed to create volume files"

>Fixes: bz#1716812
>Change-Id: I2f4c2c6d5290f066b54e1c1db19e25db9937bedb
>Signed-off-by: Atin Mukherjee 

Fixes: bz#1721106
Change-Id: I2f4c2c6d5290f066b54e1c1db19e25db9937bedb
Signed-off-by: Atin Mukherjee

Configure changes to build with python2

2019-07-18T06:20:48+00:00

Issue: On a centos7 machine with python3, glupy doesnt get built.
Throws the following:
configure: WARNING:
        ---------------------------------------------------------------------------------
        cannot build glupy. python 3.6 and python-devel/python-dev package are required.
        ---------------------------------------------------------------------------------
Cause:
glupy needs python3 with python3-devel or python2 should be used.

Fix:
We are making the configure prioritize python2 over python3.

Change-Id: I6d4ebc6d181c48cb1ccfd19a9a1793fe2cae3f27
fixes: bz#1728988
Signed-off-by: hari gowtham

gfapi: fix incorrect initialization of upcall syncop arguments

2019-07-05T09:18:37+00:00

While sending upcall notifications via synctasks, the argument used to
carry relevant data for these tasks is not initialized properly. This patch
is to fix the same.

This is backport of below mainline fix -
> fixes: bz#1718316
> patch url: https://review.gluster.org/#/c/glusterfs/+/22839/
> Signed-off-by: Soumya Koduri 

Change-Id: I9fa8f841e71d3c37d3819fbd430382928c07176c
fixes: bz#1720636
Signed-off-by: Soumya Koduri 
(cherry picked from commit bc6fd4cfa6ed34de3ffc02e2279fcc713f80f530)

upcall: Avoid sending notifications for invalid inodes

2019-07-04T06:27:48+00:00

For nameless LOOKUPs, server creates a new inode which shall
remain invalid until the fop is successfully processed post
which it is linked to the inode table.

But incase if there is an already linked inode for that entry,
it discards that newly created inode which results in upcall
notification. This may result in client being bombarded with
unnecessary upcalls affecting performance if the data set is huge.

This issue can be avoided by looking up and storing the upcall
context in the original linked inode (if exists), thus saving up on
those extra callbacks.

This is backport of below mainline fix -
> fixes: bz#1718338
> patch url: https://review.gluster.org/#/c/glusterfs/+/22840/
> Signed-off-by: Soumya Koduri 

Change-Id: I044a1737819bb40d1a049d2f53c0566e746d2a17
fixes: bz#1720634
Signed-off-by: Soumya Koduri

doc: Added release notes for 5.7

2019-07-02T04:53:18+00:00

Fixes: bz#1697986

Change-Id: I6dc17424665431957152761eaec7b6b2226ae1f0
Signed-off-by: hari gowtham