Gluster users - Nov 2019 - Proposal to change gNFS status

Hi All,

As per the discussion on https://review.gluster.org/23645, recently we
changed the status of gNFS (gluster's native NFSv3 support) feature to
'Depricated / Orphan' state. (ref:
https://github.com/gluster/glusterfs/blob/master/MAINTAINERS#L185..L189).
With this email, I am proposing to change the status again to 'Odd
Fixes'
(ref: https://github.com/gluster/glusterfs/blob/master/MAINTAINERS#L22)

TL;DR;

I understand the current maintainers are not able to focus on maintaining
it as the focus of the project, as earlier described, is keeping
NFS-Ganesha based integration with glusterfs. But, I am volunteering along
with Xie Changlong (currently working at Chinamobile), to keep the feature
running as it used to in previous versions. Hence the status of 'Odd
Fixes'.

Before sending the patch to make these changes, I am proposing it here now,
as gNFS is not even shipped with latest glusterfs-7.0 releases. I have
heard from some users that it was working great for them with earlier
releases, as all they wanted was NFS v3 support, and not much of features
from gNFS. Also note that, even though the packages are not built, none of
the regression tests using gNFS are stopped with latest master, so it is
working same from at least last 2 years.

I request the package maintainers to please add '--with gnfs' (or
--enable-gnfs) back to their release script through this email, so those
users wanting to use gNFS happily can continue to use it. Also points to
users/admins is that, the status is 'Odd Fixes', so don't expect any
'enhancements' on the features provided by gNFS.

Happy to hear feedback, if any.

Regards,
Amar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20191121/83062633/attachment.html>

On Thu, Nov 21, 2019 at 12:31 PM Amar Tumballi <amarts at gmail.com>
wrote:
> Hi All,
>
> As per the discussion on https://review.gluster.org/23645, recently we
> changed the status of gNFS (gluster's native NFSv3 support) feature to
> 'Depricated / Orphan' state. (ref:
> https://github.com/gluster/glusterfs/blob/master/MAINTAINERS#L185..L189).
> With this email, I am proposing to change the status again to 'Odd
Fixes'
> (ref: https://github.com/gluster/glusterfs/blob/master/MAINTAINERS#L22)
>
> TL;DR;
>
> I understand the current maintainers are not able to focus on maintaining
> it as the focus of the project, as earlier described, is keeping
> NFS-Ganesha based integration with glusterfs. But, I am volunteering along
> with Xie Changlong (currently working at Chinamobile), to keep the feature
> running as it used to in previous versions. Hence the status of 'Odd
> Fixes'.
>
As long as there are volunteers to keep maintaining it, I think it's a
great idea to have it.
I personally do not see the value, as I believe it's somewhat of a
redundant effort in several ways (it's not helping stabilizing having more
than one implementation, it doesn't help in improving it from features
perspective - pNFS, NFS v4.2, IPv6, performance... and it 'costs' more
in
CI and testing), but indeed if there's interest from both the users and the
development community - then sure!

> Before sending the patch to make these changes, I am proposing it here
> now, as gNFS is not even shipped with latest glusterfs-7.0 releases. I have
> heard from some users that it was working great for them with earlier
> releases, as all they wanted was NFS v3 support, and not much of features
> from gNFS. Also note that, even though the packages are not built, none of
> the regression tests using gNFS are stopped with latest master, so it is
> working same from at least last 2 years.
>
> I request the package maintainers to please add '--with gnfs' (or
> --enable-gnfs) back to their release script through this email, so those
> users wanting to use gNFS happily can continue to use it. Also points to
> users/admins is that, the status is 'Odd Fixes', so don't
expect any
> 'enhancements' on the features provided by gNFS.
>
'Odd fixes' sounds odd to me. Better come with a better terminology. ;-)
Y.
>
> Happy to hear feedback, if any.
>
> Regards,
> Amar
>
> _______________________________________________
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/441850968
>
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/441850968
>
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20191121/ee31a0ad/attachment.html>

Kudos.

Il gio 21 nov 2019, 11:31 Amar Tumballi <amarts at gmail.com> ha scritto:
> Hi All,
>
> As per the discussion on https://review.gluster.org/23645, recently we
> changed the status of gNFS (gluster's native NFSv3 support) feature to
> 'Depricated / Orphan' state. (ref:
> https://github.com/gluster/glusterfs/blob/master/MAINTAINERS#L185..L189).
> With this email, I am proposing to change the status again to 'Odd
Fixes'
> (ref: https://github.com/gluster/glusterfs/blob/master/MAINTAINERS#L22)
>
> TL;DR;
>
> I understand the current maintainers are not able to focus on maintaining
> it as the focus of the project, as earlier described, is keeping
> NFS-Ganesha based integration with glusterfs. But, I am volunteering along
> with Xie Changlong (currently working at Chinamobile), to keep the feature
> running as it used to in previous versions. Hence the status of 'Odd
> Fixes'.
>
> Before sending the patch to make these changes, I am proposing it here
> now, as gNFS is not even shipped with latest glusterfs-7.0 releases. I have
> heard from some users that it was working great for them with earlier
> releases, as all they wanted was NFS v3 support, and not much of features
> from gNFS. Also note that, even though the packages are not built, none of
> the regression tests using gNFS are stopped with latest master, so it is
> working same from at least last 2 years.
>
> I request the package maintainers to please add '--with gnfs' (or
> --enable-gnfs) back to their release script through this email, so those
> users wanting to use gNFS happily can continue to use it. Also points to
> users/admins is that, the status is 'Odd Fixes', so don't
expect any
> 'enhancements' on the features provided by gNFS.
>
> Happy to hear feedback, if any.
>
> Regards,
> Amar
>
> ________
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/118564314
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/118564314
>
> Gluster-users mailing list
> Gluster-users at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20191121/fec78956/attachment.html>

I personally wouldn't call three years ago ? when we started to deprecate
it, in glusterfs-3.9 ? a recent change.

As a community the decision was made to move to NFS-Ganesha as the
preferred NFS solution, but it was agreed to keep the old code in the tree
for those who wanted it. There have been plans to drop it from the
community packages for most of those three years, but we didn't follow
through across the board until fairly recently. Perhaps the most telling
piece of data is that it's been gone from the packages in the CentOS
Storage SIG in glusterfs-4.0, -4.1, -5, -6, and -7 with no complaints ever,
that I can recall.

Ganesha is a preferable solution because it supports NFSv4, NFSv4.1,
NFSv4.2, and pNFS, in addition to legacy NFSv3. More importantly, it is
actively developed, maintained, and supported, both in the community and
commercially. There are several vendors selling it, or support for it; and
there are community packages for it for all the same distributions that
Gluster packages are available for.

Out in the world, the default these days is NFSv4. Specifically v4.2 or
v4.1 depending on how recent your linux kernel is. In the linux kernel,
client mounts start negotiating for v4.2 and work down to v4.1, v4.0, and
only as a last resort v3. NFSv3 client support in the linux kernel largely
exists at this point only because of the large number of legacy servers
still running that can't do anything higher than v3. The linux NFS
developers would drop the v3 support in a heartbeat if they could.

IMO, providing it, and calling it maintained, only encourages people to
keep using a dead end solution. Anyone in favor of bringing back NFSv2,
SSHv1, or X10R4? No? I didn't think so.

The recent issue[1] where someone built gnfs in glusterfs-7.0 on CentOS7
strongly suggests to me that gnfs is not actually working well. Three years
of no maintenance seems to have taken its toll.

Other people are more than welcome to build their own packages from the
src.rpms and/or tarballs that are available from gluster ? and support
them. It's still in the source and there are no plans to remove it. (Unlike
most of the other deprecated features which were recently removed in
glusterfs-7.)



[1] https://github.com/gluster/glusterfs/issues/764

On Thu, Nov 21, 2019 at 5:31 AM Amar Tumballi <amarts at gmail.com> wrote:
> Hi All,
>
> As per the discussion on https://review.gluster.org/23645, recently we
> changed the status of gNFS (gluster's native NFSv3 support) feature to
> 'Depricated / Orphan' state. (ref:
> https://github.com/gluster/glusterfs/blob/master/MAINTAINERS#L185..L189).
> With this email, I am proposing to change the status again to 'Odd
Fixes'
> (ref: https://github.com/gluster/glusterfs/blob/master/MAINTAINERS#L22)
>
> TL;DR;
>
> I understand the current maintainers are not able to focus on maintaining
> it as the focus of the project, as earlier described, is keeping
> NFS-Ganesha based integration with glusterfs. But, I am volunteering along
> with Xie Changlong (currently working at Chinamobile), to keep the feature
> running as it used to in previous versions. Hence the status of 'Odd
> Fixes'.
>
> Before sending the patch to make these changes, I am proposing it here
> now, as gNFS is not even shipped with latest glusterfs-7.0 releases. I have
> heard from some users that it was working great for them with earlier
> releases, as all they wanted was NFS v3 support, and not much of features
> from gNFS. Also note that, even though the packages are not built, none of
> the regression tests using gNFS are stopped with latest master, so it is
> working same from at least last 2 years.
>
> I request the package maintainers to please add '--with gnfs' (or
> --enable-gnfs) back to their release script through this email, so those
> users wanting to use gNFS happily can continue to use it. Also points to
> users/admins is that, the status is 'Odd Fixes', so don't
expect any
> 'enhancements' on the features provided by gNFS.
>
> Happy to hear feedback, if any.
>
> Regards,
> Amar
>
> _______________________________________________
> maintainers mailing list
> maintainers at gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.gluster.org/pipermail/gluster-users/attachments/20191121/b6e17109/attachment.html>

On Thu, Nov 21, 2019 at 04:01:23PM +0530, Amar Tumballi
wrote:
> Hi All,
> 
> As per the discussion on https://review.gluster.org/23645, recently we
> changed the status of gNFS (gluster's native NFSv3 support) feature to
> 'Depricated / Orphan' state. (ref:
> https://github.com/gluster/glusterfs/blob/master/MAINTAINERS#L185..L189).
> With this email, I am proposing to change the status again to 'Odd
Fixes'
> (ref: https://github.com/gluster/glusterfs/blob/master/MAINTAINERS#L22)
I'd recommend against re-surrecting gNFS. The server is not very
extensible and adding new features is pretty tricky without breaking
other (mostly undocumented) use-cases. Eventhough NFSv3 is stateless,
the actual usage of NFSv3, mounting and locking is definitely not. The
server keeps track of which clients have an export mounted, and which
clients received grants for locks. These things are currently not very
reliable in combination with high-availability. And there is also the by
default disabled duplicate-reply-cache (DRC) that has always been very
buggy (and neither cluster-aware).

If we enable gNFS by default again, we're sending out an incorrect
message to our users. gNFS works fine for certain workloads and
environments, but it should not be advertised as 'clustered NFS'.

Instead of going the gNFS route, I suggest to make it easier to deploy
NFS-Ganesha as that is a more featured, well maintained and can be
configured for much more reliable high-availability than gNFS.

If someone really wants to maintain gNFS, I won't object much, but they
should know that previous maintainers have had many difficulties just
keeping it working well while other components evolved. Addressing some
of the bugs/limitations will be extremely difficult and may require
large rewrites of parts of gNFS.

Until now, I have not read convincing arguments in this thread that gNFS
is stable enough to be consumed by anyone in the community. Users should
be aware of its limitations and be careful what workloads to run on it.

HTH,
Niels