+++ This bug was initially created as a clone of Bug #1376692 +++ Description of problem: Since gluster-NFS is no more default NFS server for gluster volumes from 3.8.x release, it shouldn't be started by default post upgrade to >=3.8.x releases. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I need to understand the requirement here, if the setup already has an active nfs mount(s) pre upgrade I dont see a reason of disabling the service post upgrade. So in that case would there be a migration path from nfs to nfs ganesha for the existing mounts?
While I was looking at the BZ 1378677 I realized currently we don't start gNFS process in rhgs-3.2.0 post upgrade when earlier gNFS enabled. So I believe we have nothing to do here, can you cross check it Kaleb?
But Jiffin observed that when the option "nfs.disable" is explicitly set to off (not by default but if admin manually sets it) for any volume in 3.1.3, after upgrade that option will remain 'off' bringing gluster-NFS server. Jiffin shall be able to confirm it.
Downstream wants a different approach than upstream: https://github.com/gluster/glusterfs/blob/release-3.8/doc/release-notes/3.8.0.md#glusternfs-disabled-by-default > Existing volumes that have gNFS enabled will remain enabled unless explicitly > disabled. For downstream all upgrades need to have gNFS disabled, no matter if the admin explicitly enabled gNFS before the upgrade.
Patch posted downstream up for review https://code.engineering.redhat.com/gerrit/#/c/90425
(In reply to Jiffin from comment #17) > Patch posted downstream up for review > https://code.engineering.redhat.com/gerrit/#/c/90425 Please note this is a downstream only change.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.