----- Original Message ----- > From: "Amar Tumballi" <atumball@xxxxxxxxxx> > To: "Shyam" <srangana@xxxxxxxxxx>, "Vijay Bellur" <vbellur@xxxxxxxxxx>, "Prasanna Kalever" <pkalever@xxxxxxxxxx>, > "Ram Edara" <redara@xxxxxxxxxx> > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Sent: Tuesday, 30 May, 2017 6:55:07 PM > Subject: Re: Release 3.12 and 4.0: Thoughts on scope > > > I couldn't get time to get back on this list completely. While this looks > mostly fine, there are few things I wanted to add. > > * Check with few features which users are asking for long, and we are > still not able to get to it. (Is there such a list somewhere? I prefer > that to be migrated to github issues, if any). > * What would be the status of projects depending on glusterfs repo by 4.0 > timeframe. Will we have a release of those projects also? > > > * like gluster-block > * like gluster-swift > * like gluster-nagios* > * And any other integration projects (like heketi / gdeploy etc). > * > Will these projects promise any features by that time, and does any of them > require glusterfs changes? > > > For these release, how about people sending release-notes and specs before > starting to write code? :-) +100 Specs aren't used today how they are supposed to be. The intent was to do a documented design discussion involving component owners, reviewers before writing code, to avoid surprises later. Specs are archived for historical reference and is not meant to reflect the design of current implementation. Not all BZs or github issues marked as RFE need specs. Example https://review.gluster.org/#/c/17395 Patches implementing feature shouldn't be merged before the spec. Example https://review.gluster.org/#/c/16436 Feel free to do away with the 'feature page' template that was inherited from mediawiki pages. IMHO, contents of the spec should be similar to these detailed examples: https://docs.google.com/document/d/1m7pLHKnzqUjcb3RQo8wxaRzENyxq1h1r385jnwUGc2A/edit https://docs.google.com/document/d/1bbxwjUmKNhA08wTmqJGkVd_KNCyaAMhpzx4dswokyyA/edit Specs are for developer eyes only and is not targeted at users :) > Also, should we let wider user community know about these list? or is it too > early for it. They may ask for few features. > > Regards, > Amar > > > On Thu, May 18, 2017 at 3:31 PM, Soumya Koduri < skoduri@xxxxxxxxxx > wrote: > > > > > On 05/16/2017 02:10 PM, Kaushal M wrote: > > > On 16 May 2017 06:16, "Shyam" < srangana@xxxxxxxxxx > <mailto: srangana@xxxxxxxxxx >> wrote: > > Hi, > > Let's start a bit early on 3.12 and 4.0 roadmap items, as there have > been quite a few discussions around this in various meetups. > > Here is what we are hearing (or have heard), so if you are working > on any of these items, do put up your github issue, and let us know > which release you are targeting these for. > > If you are working on something that is not represented here, shout > out, and we can get that added to the list of items in the upcoming > releases. > > Once we have a good collection slotted into the respective releases > (on github), we can further announce the same in the users list as well. > > 3.12: > 1. Geo-replication to cloud (ie, s3 or glacier like storage target) > 2. Basic level of throttling support on server side to manage the > self-heal processes running. > 3. Brick Multiplexing (Better support, more control) > 4. GFID to path improvements > 5. Resolve issues around disconnects and ping-timeouts > 6. Halo with hybrid mode was supposed to be with 3.12 > 7. Procedures and code for +1 scaling the cluster? > 8. Lookup-optimized turned on by default. > 9. Thin client (or server side clustering) - phase 1. > > > 10. > We also have the IPV6 patch by FB. This was supposed to go into 3.11 > but > > > hasn't. The main thing blocking this is having an actual IPV6 > environment to test it in. > > 11. Also we would like to propose support for leases and lock-owner via gfAPI > in 3.12. > > There are already POC patches sent by Poornima and Anoop. They need testing > (have started) and updates. I have raised github-issue [1] to track the > same. > > > > > > > 4.0: (more thematic than actual features at the moment) > 1. Separation of Management and Filesystem layers (aka GlusterD2 > related efforts) > 2. Scaling Distribution logic > 3. Better consistency with rename() and link() operations > 4. Thin client || Clustering Logic on server side - Phase 2 > 5. Quota: re-look at optimal support > 6. Improvements in debug-ability and more focus on testing coverage > based on use-cases. > 7. Zero-copy Writes > > There was some effort put up by Sachin wrt this feature[2]. I would like to > take it forward and propose the design changes if needed to be consumed by > external applications (at-least existing ones like NFS-Ganesha or Samba). > Github issue#[3] > > Thanks, > Soumya > > [1] https://github.com/gluster/glusterfs/issues/213 > [2] https://review.gluster.org/#/c/14784/ > [3] https://github.com/gluster/glusterfs/issues/214 > > > > > Components moving out of support in possibly 4.0 > - Stripe translator > - AFR with just 2 subvolume (either use Arbiter or 3 way replicate) > - Re-validate few performance translator's presence. > > Thanks, > Shyam > > > > > -- > Amar Tumballi (amarts) > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxxx > http://lists.gluster.org/mailman/listinfo/gluster-devel _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
