Re: [Gluster-devel] 4.0 ideas
On Thu, May 07, 2015 at 02:15:20PM -0400, Jeff Darcy wrote: Last week, those of us who were together in Bangalore had a meeting to discuss the GlusterFS 4.0 plan. Once we'd covered what's already in the plan[1] we had a very productive brainstorming session on what else we might want to consider adding. Here are some of my notes, in no particular order, for discussion either here on the list or in person at the upcoming Barcelona summit. ... * FTP or STFP (sshfs) client using GFAPI I've proposed this as a potential intern project. Good idea :D It happens that I suggested this addition for lftp too already (for the C++ lovers): http://www.gluster.org/community/documentation/index.php/Features/lftp There are some other features that should land in 4.0, or possibly even earlier. I'll add them here for awareness, once we start looking into more details about them, we'll send notes to the mailinglists. * Kerberos support for the GlusterFS protocols Clients and servers will become able to authenticate eachother through their Kerberos TGTs. Encryption of the network transport will also be an option. This would look very much like Kerberized NFS. * Rich Access Control Lists POSIX ACLs are too limited for certain access protocols. NFSv4 and SMB are the main drivers to get support for richacls on the bricks and through libgfapi. Once NFS-Ganesha, Samba and Gluster prove that richacls fulfill their promise, it will become easier to convince the Linux kernel people to implement/accept patches for richacls too. Niels [1] http://www.gluster.org/community/documentation/index.php/Planning40 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel pgpxUiUIaBVyP.pgp Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] 4.0 ideas
On Thu, May 07, 2015 at 02:44:08PM -0400, Jeff Darcy wrote: I believe the right way to express this is: retire the Gluster NFS (gnfs) server. (Ganesha does NFSv3, and will continue to do NFSv3, as well as 4, 4.1, 4.2, and pNFS.) Personally I'd like to go further and say that any features/omissions in NFSv3 (even Ganesha's) shouldn't be fixed at this point, but for the project I think you're correct. I think the Gluster/NFS server is very useful for many users. It is extremely easy to setup, providing access to the storage alomst immediately. My suggestion would be to keep Gluster/NFS, but make it optional instead of enabled by default. I would like to see all references removed from the GlusterD management part, and have a normal systemd service that starts the Gluster/NFS server. NFS-Ganesha is definitely the future, but it is not very easy to correctly set it up can configure it. Cheers, Niels pgpG268DavwxD.pgp Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] 4.0 ideas
On Thu, May 07, 2015 at 12:04:17PM -0700, Joe Julian wrote: On 05/07/2015 11:15 AM, Jeff Darcy wrote: Last week, those of us who were together in Bangalore had a meeting to discuss the GlusterFS 4.0 plan. Once we'd covered what's already in the plan[1] we had a very productive brainstorming session on what else we might want to consider adding. Here are some of my notes, in no particular order, for discussion either here on the list or in person at the upcoming Barcelona summit. ... * Hot-spare nodes/bricks -1 From what I've seen, most users are against spending money on hardware that's not being used. An auto-rebalance, or some such mechanism, to ensure redundancy after a failure would be much more welcome. Actually, hot-spares (bricks or nodes) is quite a common question/request that I got from users who spoke to me at conferences. Something like an auto-rebalance would definitely be useful too. I guess the same detect-failure-and-fix framework would be used to make a (configurable?) decision to do a rebalance or replace-brick. Niels pgpf7r8C9Vf5A.pgp Description: PGP signature ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] 4.0 ideas
On 05/07/2015 02:15 PM, Jeff Darcy wrote: * Centralized logging - The intention of the change/move from gf_log to gf_msg was to enable centralized logging mechanisms, among other things. In the discussions do consider needs and how this can fit into the same. Ref: http://www.gluster.org/community/documentation/index.php/Features/better-logging * Finer-grain version/feature negotiation between nodes. - Adding to this, one thought for DHT was to allow/disallow clients with older layouts, using something akin to a generation number than version/feature, and can allow client to reconfigure themselves to the latest graph/conf. Just posting this here, so that it may trigger thoughts at the summit. Additions: - I would like to add a framework for fault injection I know, I had bigger dreams on this in the past, but this time around something simpler. An extensible framework that we can add fault points to, and exercise in the regression tests, or other tests, triggering specific faults, or injecting specific waits. This can help test out a lot of the new (and older) code in various scenarios. For example, exercising FOPs between a rebalance phase 1 and rebalance phase 2, which requires a _wait/sleep_ in this state to be injected in the rebalance daemon. Shyam ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] 4.0 ideas
On 05/07/2015 02:15 PM, Jeff Darcy wrote: * Retire NFSv3 I believe the right way to express this is: retire the Gluster NFS (gnfs) server. (Ganesha does NFSv3, and will continue to do NFSv3, as well as 4, 4.1, 4.2, and pNFS.) Regards -- Kaleb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] 4.0 ideas
I believe the right way to express this is: retire the Gluster NFS (gnfs) server. (Ganesha does NFSv3, and will continue to do NFSv3, as well as 4, 4.1, 4.2, and pNFS.) Personally I'd like to go further and say that any features/omissions in NFSv3 (even Ganesha's) shouldn't be fixed at this point, but for the project I think you're correct. ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] 4.0 ideas
On 05/07/2015 11:15 AM, Jeff Darcy wrote: Last week, those of us who were together in Bangalore had a meeting to discuss the GlusterFS 4.0 plan. Once we'd covered what's already in the plan[1] we had a very productive brainstorming session on what else we might want to consider adding. Here are some of my notes, in no particular order, for discussion either here on the list or in person at the upcoming Barcelona summit. * Traffic throttling Many internal services need this to keep from crowding out new user requests. +1 * Centralized logging -1 There's already 3rd party applications that do that. Is that worth the effort to duplicate something that's done very well already? * Third-party copy (server to server, at client request) AIUI both SMB and NFS can make such requests, which we currently must satisfy by bouncing data through the proxy node. We could add it to GFAPI as well, for users there who also want to avoid the extra network traffic. +1!!1!111!!1!! * Better memory management (talloc, maybe even a real garbage collector) +1 * Virtual nodes (DHT feature to improve rebalance behavior) * Hot-spare nodes/bricks -1 From what I've seen, most users are against spending money on hardware that's not being used. An auto-rebalance, or some such mechanism, to ensure redundancy after a failure would be much more welcome. * Better faiure detection Detecting failures via pairwise heartbeat (what we do now) doesn't work at scale. This might become part of the GlusterD v2 plan. * File level snapshots. * Finer-grain version/feature negotiation between nodes. Or at least one that doesn't require user intervention. Right now that mechanism sometimes fails and the user has to manually set the op-version. * Better GFID-to-path translation * Retire NFSv3 * Make snapshots more modular (not solely dependent on LVM) +1 * FTP or STFP (sshfs) client using GFAPI I've proposed this as a potential intern project. [1] http://www.gluster.org/community/documentation/index.php/Planning40 ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
