glusterfs.git/extras, branch v3.8.8

glusterd/ganesha : handle volume reset properly for ganesha options

2016-12-23T12:11:52+00:00

The "gluster volume reset" should first unexport the volume and then delete
export configuration file. Also reset option is not applicable for ganesha.enable
if volume value is "all".
This patch also changes the name of create_export_config into manange_export_config

Upstream reference :
>Change-Id: Ie81a49e7d3e39a88bca9fbae5002bfda5cab34af
>BUG: 1397795
>Signed-off-by: Jiffin Tony Thottan 
>Reviewed-on: http://review.gluster.org/15914
>Smoke: Gluster Build System 
>NetBSD-regression: NetBSD Build System 
>CentOS-regression: Gluster Build System 
>Reviewed-by: soumya k 
>Reviewed-by: Kaleb KEITHLEY 
>Signed-off-by: Jiffin Tony Thottan 

Change-Id: Ie81a49e7d3e39a88bca9fbae5002bfda5cab34af
BUG: 1405951
Signed-off-by: Jiffin Tony Thottan 
Reviewed-on: http://review.gluster.org/16054
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
Signed-off-by: Jiffin Tony Thottan 
Reviewed-on: http://review.gluster.org/16197

common-ha: add node create new node dirs in shared storage

2016-12-22T14:20:28+00:00

When adding a node to the ganesha HA cluster, create the directory
tree in shared storage for the added node and create sets of symlinks
to match what is/was created for the other nodes.  I.e. in a four
node cluster the new node needs a set of links to the four existing
nodes:
 /run/gluster/shared/nfs-ganesha/$new/nfs/{ganesha,statd}/$e1 -> e1
 /run/gluster/shared/nfs-ganesha/$new/nfs/{ganesha,statd}/$e2 -> e2
 /run/gluster/shared/nfs-ganesha/$new/nfs/{ganesha,statd}/$e3 -> e3
 /run/gluster/shared/nfs-ganesha/$new/nfs/{ganesha,statd}/$e4 -> e4
and all the existing nodes need links added for the new node:
 /run/gluster/shared/nfs-ganesha/$e1/nfs/{ganesha,statd}/$new -> new
 /run/gluster/shared/nfs-ganesha/$e2/nfs/{ganesha,statd}/$new -> new
 /run/gluster/shared/nfs-ganesha/$e3/nfs/{ganesha,statd}/$new -> new
 /run/gluster/shared/nfs-ganesha/$e5/nfs/{ganesha,statd}/$new -> new

Likewise when deleting, remove the dir and symlinks.

original change http://review.gluster.org/16036
original change release-3.9 http://review.gluster.org/16170
original change release-3.8 http://review.gluster.org/16171
master change http://review.gluster.org/16216
master BZ 1400613
release-3.9 change http://review.gluster.org/16217
release-3.9 BZ 1405576

Change-Id: I52839046745728d06ab5a07f38081c032093bff6
BUG: 1405577
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/16218
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

common-ha: add node create new node dirs in shared storage

2016-12-18T12:44:12+00:00

When adding a node to the ganesha HA cluster, create the directory
tree in shared storage for the added node and create sets of symlinks
to match what is/was created for the other nodes.  I.e. in a four
node cluster the new node needs a set of links to the four existing
nodes:
 /run/gluster/shared/nfs-ganesha/$new/nfs/{ganesha,statd}/$e1 -> e1
 /run/gluster/shared/nfs-ganesha/$new/nfs/{ganesha,statd}/$e2 -> e2
 /run/gluster/shared/nfs-ganesha/$new/nfs/{ganesha,statd}/$e3 -> e3
 /run/gluster/shared/nfs-ganesha/$new/nfs/{ganesha,statd}/$e4 -> e4
and all the existing nodes need links added for the new node:
 /run/gluster/shared/nfs-ganesha/$e1/nfs/{ganesha,statd}/$new -> new
 /run/gluster/shared/nfs-ganesha/$e2/nfs/{ganesha,statd}/$new -> new
 /run/gluster/shared/nfs-ganesha/$e3/nfs/{ganesha,statd}/$new -> new
 /run/gluster/shared/nfs-ganesha/$e5/nfs/{ganesha,statd}/$new -> new

Likewise when deleting, remove the dir and symlinks.

master BZ: 1400613
master http://review.gluster.org/#/c/16036/
release-3.9 BZ: 1405576
release-3.9 http://review.gluster.org/16170

Change-Id: Id2f78f70946f29c3503e1e6db141b66cb431e0ea
BUG: 1405577
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/16171
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

common-ha: explicitly set udpu transport for corosync

2016-12-15T18:17:08+00:00

On RHEL7 corosync uses udpu (udp unicast) by default. On RHEL6 the
default is (now) udp multi-cast. In network environments that don't
support udp multi-cast this causes the ever growing lists of
[TOTEM ] Retransmit errors.

Always specifying --transport udpu is thus a no-op on RHEL7.

Using the same transport on both RHEL6 and RHEL7 may (or may not
give similar behavior and performance--it's hard to say.

It remains a mystery why things have always worked on RHEL6 prior to
now. Further investigation is required to uncover why this is the
case.

main http://review.gluster.org/16122
main BZ 1404410
release-3.9 http://review.gluster.org/16139/
release-3.9 BZ 1405002

Change-Id: I4d0de97fe4425c47f249beaaf51aeca3e91731fa
BUG: 1405004
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/16140
Reviewed-by: soumya k 
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

extras: Include shard and full-data-heal in virt group

2016-12-15T15:49:45+00:00

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

Change-Id: Ibcfe069e2cc10cc1913ba5c9ca724b7dd3f8b147
BUG: 1375849
Signed-off-by: Krutika Dhananjay 
Reviewed-on: http://review.gluster.org/16120
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Pranith Kumar Karampuri

ganesha/scripts : use export id for dbus signals

2016-12-05T07:03:13+00:00

Currently for add export and update export parameter passed for executing those signal
is "PATH". This is based on assumption that volume name and PATH will always be same.
But it is wrong for subdir exports. The only reliable parameter in export configuration
file is "Export_Id".

Upstream reference :
>Change-Id: Ic63ff44ac7736e14502034b74beaae27292eddf9
>BUG: 1389746
>Signed-off-by: Jiffin Tony Thottan 
>Reviewed-on: http://review.gluster.org/15751
>Smoke: Gluster Build System 
>NetBSD-regression: NetBSD Build System 
>CentOS-regression: Gluster Build System 
>Reviewed-by: soumya k 
>Reviewed-by: Kaleb KEITHLEY 

Change-Id: Ic63ff44ac7736e14502034b74beaae27292eddf9
BUG: 1399635
Signed-off-by: Jiffin Tony Thottan 
Reviewed-on: http://review.gluster.org/15970
Smoke: Gluster Build System 
Reviewed-by: soumya k 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Kaleb KEITHLEY

common-ha: IPaddr RA is not stopped when pacemaker quorum is lost

2016-12-02T09:54:03+00:00

Ken Gaillot writes:
The other is pacemaker's no-quorum-policy cluster property. The
default (which has not changed) is "stop" (stop all resources).
Other values are "ignore" (act as if quorum was not lost),
"freeze" (continue running existing resources but don't recover
resources from unseen nodes) or "suicide" (shut down).

But on my four node cluster
% pcs property show no-quorum-policy
Cluster Properties:
%

i.e. shows nothing.

But:
% pcs property list --all
Cluster Properties:
...
no-quorum-policy: stop
...
%

Seems to think it knows about it.

and then
% pcs property set no-quorum-policy=stop
% pcs property show no-quorum-policy
Cluster Properties:
 no-quorum-policy: stop
%

Which looks rather inconsistent. So we will try explicitly
setting it to "stop" when there are three or more nodes.

master bug 1400237
master patch http://review.gluster.org/#/c/15981/
release-3.9 bug 1400527
release-3.9 patch http://review.gluster.org/15996

Change-Id: I47fc7ee84fcd6ad52ccb776913511978a8d517b4
BUG: 1400573
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/15997
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System

common-ha: add cluster HA status to --status output for gdeploy

2016-12-01T20:40:34+00:00

gdeploy desires a one-liner "health" assessment.

If all the VIP and port block/unblock RAs are located on their
prefered nodes and 'Started', then the cluster is deemed to be
good (healthy).

N.B. status originally only checked the "online" nodes obtained
from `pcs status` but we really want to consider all the configured
nodes, whether they are online or not.

Also one `pcs status` is enough.

master http://review.gluster.org/15882
master bug 1395648
release-3.9 http://review.gluster.org/15991
release-3.9 bug 1395649

Change-Id: Id0e0380b6982e23763edeb0488843b5363e370b8
BUG: 1395652
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-by: Arthy Loganathan 
Reviewed-by: soumya k 
Reviewed-on: http://review.gluster.org/15992
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

common-ha: nfs-grace-monitor timed out unknown error messages

2016-11-16T10:27:05+00:00

grace_mon_monitor() occasionally returns OCF_ERR_GENERIC, but it
ought to return OCF_NOT_RUNNING instead.

Change-Id: I3d550e33cc3d0a8dce4333ced72db19b3b2f4f2e
BUG: 1394226
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/15833
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: jiffin tony Thottan

common-ha: remove /etc/corosync/corosync.conf in teardown/cleanup

2016-11-15T19:45:26+00:00

In newer versions of corosync we observe that after tearing down an
existing HA cluster, when trying to set up a new cluster, `pcs cluster
start --all` will fail if corosync believes the nodes are already in
the cluster based on the presence of, and the contents of
/etc/corosync/corosync.conf

So we summarily delete it. (An alternative/work-around is to use `pcs
cluster start --force --all`)

Change-Id: I225f4e35e3b605e860ec4f9537c40ed94ac68625
BUG: 1394883
Signed-off-by: Kaleb S. KEITHLEY 
Reviewed-on: http://review.gluster.org/15845
Smoke: Gluster Build System 
Reviewed-by: soumya k 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System