Re: [Gluster-devel] [RFC] Reducing maintenance burden and moving fuse support to an external project
On Fri, Mar 03, 2017 at 12:58:12PM -0800, Joe Julian wrote: > The only concern I have is that according to the README syntax (I haven't > looked any deeper but I suspect it's a non issue) there's a lack of rdma > support. Yes, there are definitely a lot of features that we need to add. This is one of the issues that needs solving. Our FUSE exposes many more options than gfapi applications can set, I'm looking at extending the gfapi interface[2]for these as well. We'll need to test and extend gfapi+xglfs over a few releases before this really can completely replace the current FUSE support. Thanks, Niels 2. http://lists.gluster.org/pipermail/gluster-devel/2017-March/052228.html > Otherwise I'm all for anything that simplifies bug fixing and improves > stability. > > > On 03/03/2017 12:50 PM, Niels de Vos wrote: > > At the moment we have three top-level interfaces to maintain in Gluster, > > these are FUSE, Gluster/NFS and gfapi. If any work is needed to support > > new options, FOPs or other functionalities, we mostly have to do the > > work 3x. Often one of the interfaces gets forgotten, or does not need > > the new feature immediately (backlog++). This is bothering me every now > > and then, specially when bugs get introduced and need to get fixed in > > different ways for these three interfaced. > > > > One of my main goals is to reduce the code duplication, and move > > everything to gfapi. We are on a good way to use NFS-Ganesha instead of > > Gluster/NFS already. In a similar approach, I would love to see > > deprecating our xlators/mount sources[0], and have it replaced by > > xglfs[1] from Oleksandr. > > > > Having the FUSE mount binaries provided by a separate project should > > make it easier to implement things like subdirectory mounts (Samba and > > NFS-Ganesha already do this in some form through gfapi). > > > > xglfs is not packaged in any distribution yet, this allows us to change > > the current commandline interface to something we deem more suitable (if > > so). > > > > I would like to get some opinions from others, and if there are no > > absolute objections, we can work out a plan to make xglfs an alternative > > to the fuse-bridge and eventually replace it. > > > > Thanks, > > Niels > > > > > > 0. https://github.com/gluster/glusterfs/tree/master/xlators/mount > > 1. https://github.com/gluster/xglfs > > > > > > ___ > > Gluster-devel mailing list > > Gluster-devel@gluster.org > > http://lists.gluster.org/mailman/listinfo/gluster-devel > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [RFC] Reducing maintenance burden and moving fuse support to an external project
The only concern I have is that according to the README syntax (I haven't looked any deeper but I suspect it's a non issue) there's a lack of rdma support. Otherwise I'm all for anything that simplifies bug fixing and improves stability. On 03/03/2017 12:50 PM, Niels de Vos wrote: At the moment we have three top-level interfaces to maintain in Gluster, these are FUSE, Gluster/NFS and gfapi. If any work is needed to support new options, FOPs or other functionalities, we mostly have to do the work 3x. Often one of the interfaces gets forgotten, or does not need the new feature immediately (backlog++). This is bothering me every now and then, specially when bugs get introduced and need to get fixed in different ways for these three interfaced. One of my main goals is to reduce the code duplication, and move everything to gfapi. We are on a good way to use NFS-Ganesha instead of Gluster/NFS already. In a similar approach, I would love to see deprecating our xlators/mount sources[0], and have it replaced by xglfs[1] from Oleksandr. Having the FUSE mount binaries provided by a separate project should make it easier to implement things like subdirectory mounts (Samba and NFS-Ganesha already do this in some form through gfapi). xglfs is not packaged in any distribution yet, this allows us to change the current commandline interface to something we deem more suitable (if so). I would like to get some opinions from others, and if there are no absolute objections, we can work out a plan to make xglfs an alternative to the fuse-bridge and eventually replace it. Thanks, Niels 0. https://github.com/gluster/glusterfs/tree/master/xlators/mount 1. https://github.com/gluster/xglfs ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] [RFC] Reducing maintenance burden and moving fuse support to an external project
At the moment we have three top-level interfaces to maintain in Gluster, these are FUSE, Gluster/NFS and gfapi. If any work is needed to support new options, FOPs or other functionalities, we mostly have to do the work 3x. Often one of the interfaces gets forgotten, or does not need the new feature immediately (backlog++). This is bothering me every now and then, specially when bugs get introduced and need to get fixed in different ways for these three interfaced. One of my main goals is to reduce the code duplication, and move everything to gfapi. We are on a good way to use NFS-Ganesha instead of Gluster/NFS already. In a similar approach, I would love to see deprecating our xlators/mount sources[0], and have it replaced by xglfs[1] from Oleksandr. Having the FUSE mount binaries provided by a separate project should make it easier to implement things like subdirectory mounts (Samba and NFS-Ganesha already do this in some form through gfapi). xglfs is not packaged in any distribution yet, this allows us to change the current commandline interface to something we deem more suitable (if so). I would like to get some opinions from others, and if there are no absolute objections, we can work out a plan to make xglfs an alternative to the fuse-bridge and eventually replace it. Thanks, Niels 0. https://github.com/gluster/glusterfs/tree/master/xlators/mount 1. https://github.com/gluster/xglfs signature.asc Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] Announcing release 3.11 : Scope, schedule and feature tracking
On 03/03/2017 07:23 PM, Shyam wrote: On 03/03/2017 06:44 AM, Prashanth Pai wrote: On 02/28/2017 08:47 PM, Shyam wrote: We should be transitioning to using github for feature reporting and tracking, more fully from this release. So once again, if there exists any confusion on that front, reach out to the lists for clarification. I see that there was a discussion on this on the maintainers ML [1]. If it is not too late or if I may cast vote as a non-maintainer, I prefer to have bugzilla for tracking bugs and the users ML for queries. I see many 'issues' on the github page which are mostly candidates for gluster-users ML. +1 to that Ok, there is some confusion here I think ;) So, - github issues is for features *only* - Issues are *not* for bugs or a substitute for ML posts/discussions - The proposal in maintainers for the same (i.e [1]) did not go through, and hence was never proposed to the devel and users groups So to make this clear in github, this [2] commit is put up for review (and now merged and live, check [3]), that will clarify this for users coming into github to file issues. If users still do file issues beyond this information, we can politely redirect them to the ML or BZ and close the issue. Further, thanks to folks who still have been responding to queries over github issues (which has increased in frequency in the recent past). HTH Yes, this makes sense! Thanks Shyam. and thanks for the shout out, Shyam [1] http://lists.gluster.org/pipermail/maintainers/2017-February/002195.html [2] Review on github issue template: https://review.gluster.org/#/c/16795/2/.github/ISSUE_TEMPLATE [3] New issue in glusterfs github view: https://github.com/gluster/glusterfs/issues/new ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] Announcing release 3.11 : Scope, schedule and feature tracking
On 03/03/2017 06:44 AM, Prashanth Pai wrote: On 02/28/2017 08:47 PM, Shyam wrote: We should be transitioning to using github for feature reporting and tracking, more fully from this release. So once again, if there exists any confusion on that front, reach out to the lists for clarification. I see that there was a discussion on this on the maintainers ML [1]. If it is not too late or if I may cast vote as a non-maintainer, I prefer to have bugzilla for tracking bugs and the users ML for queries. I see many 'issues' on the github page which are mostly candidates for gluster-users ML. +1 to that Ok, there is some confusion here I think ;) So, - github issues is for features *only* - Issues are *not* for bugs or a substitute for ML posts/discussions - The proposal in maintainers for the same (i.e [1]) did not go through, and hence was never proposed to the devel and users groups So to make this clear in github, this [2] commit is put up for review (and now merged and live, check [3]), that will clarify this for users coming into github to file issues. If users still do file issues beyond this information, we can politely redirect them to the ML or BZ and close the issue. Further, thanks to folks who still have been responding to queries over github issues (which has increased in frequency in the recent past). HTH and thanks for the shout out, Shyam [1] http://lists.gluster.org/pipermail/maintainers/2017-February/002195.html [2] Review on github issue template: https://review.gluster.org/#/c/16795/2/.github/ISSUE_TEMPLATE [3] New issue in glusterfs github view: https://github.com/gluster/glusterfs/issues/new ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] Announcing release 3.11 : Scope, schedule and feature tracking
> On 02/28/2017 08:47 PM, Shyam wrote: > > We should be transitioning to using github for feature reporting and > > tracking, more fully from this release. So once again, if there exists > > any confusion on that front, reach out to the lists for clarification. > > I see that there was a discussion on this on the maintainers ML [1]. If > it is not too late or if I may cast vote as a non-maintainer, I prefer > to have bugzilla for tracking bugs and the users ML for queries. I see > many 'issues' on the github page which are mostly candidates for > gluster-users ML. +1 to that > > Regards, > > Ravi > > > [1] http://lists.gluster.org/pipermail/maintainers/2017-February/002195.html > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://lists.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] [Gluster-users] Announcing release 3.11 : Scope, schedule and feature tracking
On 02/28/2017 08:47 PM, Shyam wrote: We should be transitioning to using github for feature reporting and tracking, more fully from this release. So once again, if there exists any confusion on that front, reach out to the lists for clarification. I see that there was a discussion on this on the maintainers ML [1]. If it is not too late or if I may cast vote as a non-maintainer, I prefer to have bugzilla for tracking bugs and the users ML for queries. I see many 'issues' on the github page which are mostly candidates for gluster-users ML. Regards, Ravi [1] http://lists.gluster.org/pipermail/maintainers/2017-February/002195.html ___ Gluster-devel mailing list Gluster-devel@gluster.org http://lists.gluster.org/mailman/listinfo/gluster-devel
