On Fri, Mar 7, 2014 at 11:56 AM, Jeff Darcy <jda...@redhat.com> 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