glusterfs.git/extras/ganesha/scripts, branch release-3.7

ganesha/scripts : use export id for dbus signals

2016-12-19T12:46:10+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: 1405918
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 
(cherry picked from commit beace6aed3ef27e1e55a420d606ecdfbd56b32b2)
Reviewed-on: http://review.gluster.org/16194

common-ha: race/timing issue setting up cluster

2016-06-24T16:42:14+00:00

The ganesha_grace resource agent can start before the ganesha_mon
resource agent, with the result that the crm_attribute that
ganesha_grace expects to find has not been created yet.

This is never (never? Or just so rarely that it has never actually
been seen during development) seen with four nodes, but with just
two nodes it's very repeatable.

Note that when long (FQDN) names are used it is not unexpected to
see Failed Actions in the output of `pcs status`, e.g.:

* nfs-grace_monitor_5000 on node1.fully.qualified.domain.name.com
'unknown error' (1): call=20, status=complete, exitreason='none',
last-rc-change='Wed Jun  1 12:32:32 2016', queued=0ms, exec=0ms
* nfs-grace_monitor_5000 on node2.fully.qualified.domain.name.com
'unknown error' (1): call=18, status=complete, exitreason='none',
last-rc-change='Wed Jun  1 12:32:42 2016', queued=0ms, exec=0ms

and as long as all the ganesha_grace_clone and cluster_ip-1
resource agents are in Started state then this is okay.

backport master:
> http://review.gluster.org/14607
> BUG: 1341768
release-3.8
> http://review.gluster.org/14609
> BUG: 1341770

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

common-ha: wait for cluster to elect DC before accessing CIB

2016-05-24T09:36:31+00:00

access attempts, e.g. `pcs property set stonith-enabled=false`
will fail (or time out) if attempted "too early", i.e. before
the cluster has elected its DC.

see https://bugzilla.redhat.com/show_bug.cgi?id=1336947#c3 and
https://bugzilla.redhat.com/show_bug.cgi?id=1320740

Change-Id: Ifc0aa7ce652c1da339b9eb8fe17e40e8a09b1096
BUG: 1336948
Signed-off-by: Kaleb S KEITHLEY 
Reviewed-on: http://review.gluster.org/14428
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: soumya k 
Reviewed-by: jiffin tony Thottan

common-ha: stonith-enabled option set error in new pacemaker

2016-05-19T10:17:30+00:00

Setting the option too early results in an error in newer versions
of pacemaker. Postpone setting the option in order for it to succeed.

N.B. We do not use a fencing agent. Yes, we know this is "not supported."

Backport of mainline
>> http://review.gluster.org/#/c/14404/
>> BUG: 1336945
>> Change-Id: I86953fdd67e6736294dbd2d0795611837188bd9d
release-3.8
> http://review.gluster.org/#/c/14405/
> BUG: 1336947
> Change-Id: I402992bcb90a92dbcc915a75fe03b25221625e98

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

ganesha/scripts : Fixing refresh config in ganesha-ha.sh

2016-05-16T18:05:52+00:00

The change http://review.gluster.org/#/c/14225/ cause a regression
for refresh config funtion in ganesha-ha.sh due to a invalid usage
of awk arguement.

This is backport of below mainstream bug -
        http://review.gluster.org/14325

Change-Id: Id5adfb12f99b29bdb3531773cd34bd67cfff8768
BUG: 1336331
Signed-off-by: Soumya Koduri 
Signed-off-by: Jiffin Tony Thottan 
Reviewed-on: http://review.gluster.org/14325
Reviewed-by: Kaleb KEITHLEY 
Reviewed-by: Niels de Vos 
Reviewed-on: http://review.gluster.org/14353
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
CentOS-regression: Gluster Build System

glusterd-ganesha : copy ganesha export configuration files during reboot

2016-05-06T12:59:44+00:00

glusterd creates export conf file for ganesha using hook script during
volume start and ganesha_manage_export() for volume set command. But this
routine is not added in glusterd restart scenario.
Consider the following case, in a three node cluster a volume got exported
via ganesha while one of the node is offline(glusterd is not running).
When the node comes back online, that volume is not exported on that node
due to the above mentioned issue.
Also I have removed unused variables from glusterd_handle_ganesha_op()
For this patch to work pcs cluster should running on that be node.

Upstream reference
>Change-Id: I5b2312c2f3cef962b1f795b9f16c8f0a27f08ee5
>BUG: 1330097
>Signed-off-by: Jiffin Tony Thottan i
>Reviewed-on: http://review.gluster.org/14063
>Smoke: Gluster Build System 
>NetBSD-regression: NetBSD Build System 
>CentOS-regression: Gluster Build System 
>Reviewed-by: soumya k 
>Reviewed-by: Atin Mukherjee 

Change-Id: I5b2312c2f3cef962b1f795b9f16c8f0a27f08ee5
BUG: 1333661
Signed-off-by: Jiffin Tony Thottan 
Reviewed-on: http://review.gluster.org/14233
Smoke: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: Atin Mukherjee 
CentOS-regression: Gluster Build System

NFS-Ganesha : Parse the Export_Id correctly for unexporting volume

2016-05-06T06:19:13+00:00

Currently export id parsed using "cut -d ' ' -f8" which might endup
in giving wrong value. In case of multiple space chracter, output
may differ. In this all those instance will replaced by awk call

>Change-Id: I60dea8ce116900da3c1fc9badf898e51183a2ca1
>BUG: 1333319
>Signed-off-by: Jiffin Tony Thottan 
>Reviewed-on: http://review.gluster.org/14225
>Smoke: Gluster Build System 
>NetBSD-regression: NetBSD Build System 
>CentOS-regression: Gluster Build System 
>Reviewed-by: soumya k 
>Reviewed-by: Kaleb KEITHLEY 
>(cherry picked from commit 5440bad91026f27399df51856176aef85c1fcf4d)

Change-Id: I60dea8ce116900da3c1fc9badf898e51183a2ca1
BUG: 1333528
Signed-off-by: Jiffin Tony Thottan 
Reviewed-on: http://review.gluster.org/14231
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System 
Reviewed-by: soumya k

common-ha: continuous grace_mon log messages in /var/log/messages

2016-04-28T10:20:02+00:00

messages are seen on RHEL6.x and RHEL7.1 and earlier versions of
pacemaker. (And RHEL7.2 with RHEL7.1 pacemaker packages.)

It's not possible to query attrd attributes in the older version,
only set/update/clear them. The messages come from invalid attempts
to query the attributes.

However it is possible to query crm attributes. The fix here is to
create a "shadow" crm attribute for the attrd attribute. Changes are
made to both, queries are made on the crm attribute.

(Resource Agents "follow" the attrd attribute using constraint locations,
so we must keep the attrd attribute.)

Backport of
> Change-Id: I84ac1a80673e528d98b67b7d5062e21dcf744d4a
> BUG: 1324509
> http://review.gluster.org/#/c/13919/

Change-Id: I7301c48849496be026ef598c588e78c68f273a8a
BUG: 1324510
Signed-off-by: Kaleb S KEITHLEY 
Reviewed-on: http://review.gluster.org/13920
Reviewed-by: Niels de Vos 
NetBSD-regression: NetBSD Build System 
Smoke: Gluster Build System 
CentOS-regression: Gluster Build System 
Reviewed-by: soumya k

ganesha: Include a script to generate epoch value

2016-03-21T10:51:28+00:00

In a NFS-Ganesha HA cluster setup, for NFS clients to recover state
succesfully post failover, the NFS-servers should start with a unique
epoch value.

With NFS-Ganesha 2.3, the service accepts an option "EPOCH_EXEC" which
takes path of the script, generating epoch value. This script is executed before
starting nfs-ganesha service so that the generated epoch value is used
while bringing up the service.

This patch includes the script to be used by nfs-ganesha+gluster setup.

The epoch value is computed as follows -
       - first 32-bit contains the now() time
       - rest 32-bit value contains the local glusterd node uuid

Change-Id: I876ea5a3730d7c6b40503e0fec16a4a142c54a36
BUG: 1317482
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/13716
Smoke: Gluster Build System 
Reviewed-by: jiffin tony Thottan 
Reviewed-by: Kaleb KEITHLEY 
CentOS-regression: Gluster Build System 
NetBSD-regression: NetBSD Build System

nfs-ganesha: pcs cluster setup needs '--name' option

2016-03-04T02:11:14+00:00

Even on fedora machines (on f22, f23), pcs cluster setup CLI
expects '--name' to be provided. This patch addresses the same.

Change-Id: Id33c8bbdc33955dd54729b10c720f4fa646f7e8c
BUG: 1314204
Signed-off-by: Soumya Koduri 
Reviewed-on: http://review.gluster.org/13590
Smoke: Gluster Build System 
Reviewed-by: jiffin tony Thottan 
CentOS-regression: Gluster Build System 
Reviewed-by: Kaleb KEITHLEY 
NetBSD-regression: NetBSD Build System