Re: [Gluster-devel] Glusterd: A New Hope

[Stephan von Krawczynski]

On Sun, 24 Mar 2013 19:03:07 -0400
Jeff Darcy <address@hidden> wrote:

> On 03/24/2013 04:43 AM, Stephan von Krawczynski wrote:
> > So the automated distribution of the vol-files does not help
> > the majority at all.
> 
> It's not just about distribution of volfiles.  It's also about ensuring
> their consistency across many servers and clients, and handling dynamic
> updates.  For dynamic configuration changes without reboots or even
> remounts, you either need glusterd or you need to reinvent a good
> portion of it.  Even you should be able to appreciate the value of that,
> since dynamic configuration speeds the tuning process.  Then there are a
> whole bunch of other features that I mentioned in my last reply, which
> you should read this time before rushing to give the broken record
> another spin.

Really, the project is not in a state of code stability that one with a clear
mind would put his data through _online_ configuration changes. You really
want to debug situations with online config changes that exploded or showed
strange effects afterwards?
 
> > you just
> > said you cannot solve this by yourself and want to drop it on external
> > know-how
> 
> Nobody said anything of the sort.  We *can* solve it for ourselves, but
> there's no reason we should expend our own resources to solve the parts
> of the problem that are already well solved elsewhere.

Hm, quite a lot of things in software are already solved somewhere. The thing
is you would only trust code of unknown sources and quality if you have some
high pressure on you. Is there some pressure on you to rush into lending code
based on java, python or other script stuff?
I have the strong impression you are pressed to release something in a
timeline and for reasons currently untold.
What is the reason for this rush of features and increasing instability, nfs
with server-based replication and so on. All things that the original project
really never talked about.

>  There's no
> question that there will still be plenty of domain-specific
> functionality left for us to deal with ourselves.  Leveraging other
> projects is just basic software-engineering good sense, as it allows us
> to devote more resources to enhancements in other areas - including
> those you've said need improvement.  Reinventing the wheel would be
> stupid, and forcing each user to reinvent their own would be worse.

You would only do this if you had a clear time limit to reach some goal. If
your goal would be to make a well-defined, stable and long term  GPL project
really nobody would ask questions like these. Not in the GPL part of the
software-engineering world. Your goals look externally defined and not based
on the project itself.

-- 
Regards,
Stephan