Re: [Gluster-Maintainers] Proposal to change gNFS status

2019-11-25 Thread Amar Tumballi
Responses inline.

On Fri, Nov 22, 2019 at 6:04 PM Niels de Vos  wrote:

> 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.


I too am against adding the features/enhancements to gNFS. It doesn't make
sense. We are removing features from glusterfs itself, adding features to
gNFS after 3 years wouldn't even be feasible.

I guess you missed the intention of my proposal. It was not about
'resurrecting' gNFS to 'Maintained' or 'Supported' status. It was about
taking it out of 'Orphan' status, because there are still users who are
'happy' with it. Hence I picked the status as 'Odd Fixes' (as per
MAINTAINERS file, there was nothing else which would give meaning of *'This
feature is still shipped, but we are not adding any features or not
actively maintaining it'. *



> 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'.
>
>
I didn't talk or was intending to go this route. I am not even talking
about making gNFS 'default' enable. That would take away our focus on
glusterfs, and different things we can solve with Gluster alone. Not sure
why my email was taken as there would be focus on gNFS.


> 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.
>
>
I believe this is critical, and we surely need to work on it. But doesn't
come in the way of doing 1-2 bug fixes in gNFS (if any) in a release.


> 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.
>

Yes, that awareness is critical, and it should exist.


> 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.
>

In this thread, Xie mentioned that he is managing gNFS on 1000+ servers
with 2000+ clients (more than 24 gluster cluster overall) for more than 2
years now. If that doesn't sound as 'stability', not sure what sounds as.

I agree that the users should be careful about the proper usecase to use
gNFS. I am even open to say we should add a warning or console log in
gluster CLI when 'gluster volume set  nfs.disable false' is performed,
saying it is advised to move to NFS-Ganesha based approach, and give a URL
link in that message. But the whole point is, when we make a release, we
should still ship gNFS as there are some users, very happy with gNFS, and
their usecases are properly handled by gNFS in its current form itself. Why
make them unhappy, or shift to other projects?

End of the day, as developers it is our duty to make sure we suggest the
best technologies to users, but the intentions should always be to make
sure we solve problems. If there are already solved problems, why resurface
them in the name of better technology?

So, again, my proposal is, to keep gNFS in the codebase (not as Orphan),
and continue to make releases with gNFS binary shipped when we make
release, not to make the focus of project to start working on enhancements
of gNFS.

Happy to answer if anyone has further queries.

I have sent a patch https://review.gluster.org/23738 for the same, and I
see people commenting already on that. I agree that Xie's contributions to
Gluster may need to increase (specifically in gNFS component) to be called
as MAINTAINER. Happy to introduce him as 'Peer' and change the title later
when it is time. Jiffin, thanks for volunteering to have a look on patches
when you have ti

Re: [Gluster-Maintainers] Proposal to change gNFS status

2019-11-22 Thread Niels de Vos
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

___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers


Re: [Gluster-Maintainers] Proposal to change gNFS status

2019-11-22 Thread Markus Seywald
Hi Everyone,

Just an Feedback from 1 User End.

We used GNFS with NFS3 now since  some years.  The 3.12.15 have some Bugs,… but 
it’s running most stable in comparisons to older Versions.

NFS-Ganesha we where not able to get it stable since Years. NFS-Ganesha is very 
instable once its getting used with VMware (6.0/6.7). Instable in such Way 
making it unusable. Even 2.8.x. The Idea of using NFS4.1 with Vmware was an 
great Mind,……. But never worked so far. Vmware just support “Session Trunking” 
and not pnfs in general. They don’t support using non Vsan, binded to 
open-source community. I’am not sure how other Hypervisor works with,……

Also I think there is a big Complication once it comes to Issues once 2 
Open-Source Products are in use. Once an Issue appears and not clear what ever 
End is the root Cause,… could be an extensive Process to get a Fix for.

So looking forward, on my End I really would appreciate if GNFS would be as a 
Default Package part of Gluster. As it’s the most simple Way providing Peoples 
an easy NFS Solution.  Glusterfs as a Client is not supported or available for 
each OS. It would be good providing “Fixes” once there are Bugs with newer 
Glusterfs Versions with GNFS in use (like #764,#765).

Also I would be more then happy if Devs would also deep Focus support Matrix 
with Hypervisors and to make it stable for most common ones like Vmware. May 
Hyper-V/KVM as well. (nfs-ganesha, gluster,..)

Reason why I’am thinking this Way from User-End is following:

Markets are moving very very fast. Everything need to get more stable, more 
efficient and flexible with the tiniest Effort possible. This means as well 
based on Costs > Reason why Open-Source getting more and more interesting in 
Total. Changing Products causing opposite Situation. Biggest Kickback is once 
Products getting changed. Leading to Risks Use Cases not working anymore or if 
lots Bugs/Issues arise.  That can happen with Fully Payed Products as well > 
but there is then a big Support Channel behind.

Top Leader in Virtualization Sector also focusing Kubernetes and combining 
Stacks for easier usages.

So I think it would be really really good if gluster and NFS-ganesha  getting 
also fully adopted for the Virtualization Solutions.  As this World is changing 
more and more into this Layers. And more Activities into this Direction we see 
in the Future.

I understand this is may just some Words from 1 user,…. But may some others 
thinking Similar.

Appreciated and Thx for Reading.

Max

From: Amar Tumballi 
Sent: Donnerstag, 21. November 2019 11:31
To: GlusterFS Maintainers 
Cc: Gluster Devel ; Gluster users maillist 
; xiechanglong.d 
Subject: 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


Privacy Notice: If you are receiving this email it is because you have given us 
your email address or we have a legitimate business
interest with your organisation. Beeks Financial Cloud will not retain any of 
your personal information without lawful reason to do so.
You have the right to request that we remove your email address and other 
personal details at any time.
Read our full Data Protection 
Policy and Privacy 
Notice.
Beeks Financial Cloud Group plc is incorporated in Scotland with regi

Re: [Gluster-Maintainers] Proposal to change gNFS status

2019-11-21 Thread Kaleb Keithley
Independent of anything else—

Maintain it. Send patches to gerrit. Get the requisite +2 reviews on the
patches. Amar still has commit privs AFAIK; he can merge anything that gets
two votes.

It's open source meritocracy.

If there's real support for it then it makes a stronger case for adding it
back to the community packages.

On Thu, Nov 21, 2019 at 4:14 PM Kaleb Keithley  wrote:

> 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  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@gluster.org
>> https://lists.gluster.org/mailman/listinfo/maintainers
>>
>
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers


Re: [Gluster-Maintainers] Proposal to change gNFS status

2019-11-21 Thread Kaleb Keithley
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  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@gluster.org
> https://lists.gluster.org/mailman/listinfo/maintainers
>
___
maintainers mailing list
maintainers@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers


[Gluster-Maintainers] Proposal to change gNFS status

2019-11-21 Thread Amar Tumballi
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@gluster.org
https://lists.gluster.org/mailman/listinfo/maintainers