Re: [Gluster-devel] Proposal: GlusterFS Quattro
On Fri, Mar 7, 2014 at 11:56 AM, Jeff Darcy wrote: > > Given the background, it only makes sense to retain the guiding > principles of > > the feedback, and reconcile the changes proposed to management layer in > the > > two proposals and retain the scope of 4.x to management changes. > > > Thoughts? > > I think we need to take a more careful look at dependencies between various > items before we decide what should be in 4.0 vs. earlier/later. For > example, > several other features depend on being able to subdivide storage that the > user gives us into smaller units. That feature itself depends on > multiplexing > those smaller units (whether we call them s-bricks or something else) onto > fewer daemons/ports. So which one is the 4.0 feature? If we have a clear > idea of which parts are independent and which ones must be done > sequentially, > then I think we'll be better able to "draw a line" which separates 3.x from > 4.x at the most optimal point. > The "brick model" is probably the borderline item which touches upon both management layer and data layer to some extent. Decreasing the number of processes/ports in general is a good thing, and to that end we need our brick processes to be more flexible/dynamic (able to switch a graph on the fly, add a new export directory on the fly etc.) - which is completely lacking today. I think, by covering this piece (brick model) we should be mostly able to classify rest of the changes into "management" vs "data path" in a more clear way. That being said we still need a low level design of how to make the brick process more dynamic (though it is mostly a matter of just "getting it done") Avati ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Proposal: GlusterFS Quattro
> Given the background, it only makes sense to retain the guiding principles of > the feedback, and reconcile the changes proposed to management layer in the > two proposals and retain the scope of 4.x to management changes. > Thoughts? I think we need to take a more careful look at dependencies between various items before we decide what should be in 4.0 vs. earlier/later. For example, several other features depend on being able to subdivide storage that the user gives us into smaller units. That feature itself depends on multiplexing those smaller units (whether we call them s-bricks or something else) onto fewer daemons/ports. So which one is the 4.0 feature? If we have a clear idea of which parts are independent and which ones must be done sequentially, then I think we'll be better able to "draw a line" which separates 3.x from 4.x at the most optimal point. ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Proposal: GlusterFS Quattro
On Fri, Mar 7, 2014 at 8:13 AM, Jeff Darcy wrote: > As a counterpoint to the current GlusterFS proposal, I've written up a > bunch of > ideas that I'm collectively calling GlusterFS Quattro. It's in Google > Docs so > that people can comment. Please do. ;) > > http://goo.gl/yE3O4j Thanks for sharing this Jeff. Towards the end of my visit to the Bangalore Red Hat office this time (from which I just returned a couple days ago) we got to discuss the 4.x proposal from a high level (less about specifics, more about "in general"). A concern raised by many was that if a new release is a "too radical" (analogy given was samba4 vs samba3 - coincidentally the same major number), it would result in way too much confusion and overhead (e.g lots of people want to stick with 3.x as 4.x is not yet stable, and this results in 3.x getting "stabler" and be a negative incentive to move over to 4.x, especially when distributions/ISVs are concerned). The conclusion was that, the 4.x proposal would be downsized to only have the management layer changes, while the data layer (EHT, stripe etc) changes be introduced piece by piece (as they get ready) independent of whether the current master is for 3.x or 4.x. Given the background, it only makes sense to retain the guiding principles of the feedback, and reconcile the changes proposed to management layer in the two proposals and retain the scope of 4.x to management changes. Thoughts? Avati ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Proposal: GlusterFS Quattro
On Fri, Mar 7, 2014 at 11:26 AM, Justin Clift wrote: > Port usage at the moment is such a pain (and not just for scalability). :/ I agree! The only sane way I know to manage the whitelist of ports is with Puppet-Gluster... It took me a while to get this code right, so hopefully it can be of benefit to you. ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Proposal: GlusterFS Quattro
On 07/03/2014, at 4:13 PM, Jeff Darcy wrote: > As a counterpoint to the current GlusterFS proposal, I've written up a bunch > of > ideas that I'm collectively calling GlusterFS Quattro. It's in Google Docs so > that people can comment. Please do. ;) > > http://goo.gl/yE3O4j This one would make implementation behind firewalls a lot easier/possible: "... we should revive the notion (already implemented in HekaFS ages ago) of having a single daemon on a single port provide service for many bricks." Port usage at the moment is such a pain (and not just for scalability). :/ + Justin -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
