Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1414998

Summary:	setting for nfs-disable changed when upgrading from 3.7.x to 3.9.0
Product:	[Community] GlusterFS	Reporter:	Aleks <alex>
Component:	nfs	Assignee:	Kaleb KEITHLEY <kkeithle>
Status:	CLOSED EOL	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	3.9	CC:	amukherj, bugs, jthottan, kkeithle, ndevos
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-03-08 12:32:17 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Aleks 2017-01-19 22:37:09 UTC

Description of problem:

i was using gluster 3.7.18 and upgraded to 3.9.0 offline (i was using dispersed volumes which didn't support online upgrades).

after i started glusterd back up on 3.9.0 i noticed my nfs share was no longer working.. ran showmount and saw it could not communicate with rpc.  finally came across the nfs-disable setting and the value was now ON.

Version-Release number of selected component (if applicable):
3.7.18 -> 3.9.x (gluster-server) (running on CentOS 7.2 dom0 (xenserver7))

How reproducible:
saw this on two different cluster upgrades

Steps to Reproduce:
1. install 3.7.18, create volume, verify NFS works
2. disable gluster, install 3.9.0 software
3. start glusterd back up, NFS will not be working

Actual results:
NFS services functional

Expected results:
NFS services disabled

Additional info:
per #gluster on freenode IRC:

<aleksk> i notice that with 3.9.0, the default is to have nfs.disable set to ON for volumes
<aleksk> not only for newly created volumes but for volumes that i had created with 3.7.x (nfs was working before but after upgrading to 3.9.0 it stopped working and it took me a little bit to realize that the default
  changed
<aleksk> not my call to change defaults, but at the same time can't say i'm a fan of not preserving settings from previously generated versions 
<JoeJulian> aleksk: Good point. Please file a bug report.
<glusterbot> https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS
<JoeJulian> This occurred because the 3.7 volume had no specific setting regarding that as it was enabled by default. The upgrade process should specifically set nfs on if it wasn't set prior to upgrading.
<aleksk> set nfs on meaning enable nfs, or set nfs-disable on ? 
<aleksk> i am not happy with the naming of the setting name either.. it's awkward having a negative setting name 
<JoeJulian> I agree

Comment 1 Atin Mukherjee 2017-01-20 01:14:22 UTC

This is a call which NFS team took on going with this behavior, assigning it to nfs component.

Comment 2 Niels de Vos 2017-01-24 12:32:00 UTC

Jiffin has been looking into the specifics. The plan has always been to keep Gluster/NFS enabled for upgrades, however it should be disabled for new installations. Gluster/NFS is being deprecated and it is strongly suggested to move to NFS-Ganesha.

Jiffin, do you know if there are any patches missing to keep Gluster/NFS enabled on upgrade?

Comment 3 Kaushal 2017-03-08 12:32:17 UTC

This bug is getting closed because GlusterFS-3.9 has reached its end-of-life [1].

Note: This bug is being closed using a script. No verification has been performed to check if it still exists on newer releases of GlusterFS.
If this bug still exists in newer GlusterFS releases, please open a new bug against the newer release.

[1]: https://www.gluster.org/community/release-schedule/