Re: [Gluster-devel] Performance Translators' Stability and Usefulness

[Gordan Bobic]

Shehjar Tikoo wrote:

> > > > Finally - which translators are deemed stable (no know issues - 
> > > > memory leaks/bloat, crashes, corruption, etc.)?
> > > We can definitely vouch for a higher degree of stability of the 
> > > releases. Otherwise, I dont think there is any performance translator 
> > > we can call completely stable/mature because of the roadmap we have 
> > > for constantly upgrading algorithms, functionality,
> > >  etc.
> >
> > When will the Gluster team be able to deliver a stable, mature, and 
> > reliable version of GlusterFS?
>
> Continuing from what I said earlier, the fact that GlusterFS releases
> work in a stable manner is shown by the deployments among our
> customers.
>
> At the same time, are we satisfied with the experience of non-paying
> users?
> No. I accept there are bottlenecks in our processes. We
> acknowledge that and have been working on fixing them.

I'm glad the issue of paying vs. non-paying customers has been brought 
up. I have mentioned to some of the development team that I am not 
averse to the idea of becoming a paying customer, but the enthusiasm for 
encouraging this just didn't seem to be there. The two things I would 
potentially be interested in are:

1) Specific bug-fix sponsorship
2) Feature sponsorship

From what I can tell, however, the developers' operating model isn't 
geared up toward that.

> > When will regression tests be used? It's been months now since this 
> > bug, and still I don't see any sign of the use of this simple, 
> > industry-standard technique to minimise the risk of such issues 
> > slipping through again.
>
> I think the QA folks have done some really good work in stabilizing
> GlusterFS over the last year or so. The result is there to see in the
> 2.0.X releases.

I have to say that up until 2.0.2, which works reasonably well, the path 
from late 1.4.x that became 2.0.0qa1 up to and including 2.0.1 has been 
more than a little dicey. That's a long time to stabilize a release.

I think there needs to be a split between stable (bug fixes _ONLY_!) and 
development releases (new/experimental features, redesign of parts of 
the system such as format of xattr metadata, etc.). And the priority 
should be given to stable release bug fixes under almost all 
circumstances. That way those that want new features can decide for 
themselves if the stability trade-off is worth it, and those of us who 
are happy with a smaller feature set but require very high stability 
don't have to suffer the instability caused by new and experimental 
features. What seems to have happened since the 1.3/1.4 split, is that 
support of the stable releases has been effectively dropped in favour of 
pouring all development effort into 1.4->2.0 releases. This left the 
users whose first priority is stability in a position where they cannot 
seriously consider using the software in a production environment.

> > Why wasn't this prioritised after such a disasterous bug?
>
> It could've been for any number of reasons ranging from problems with
> reproducing it, limited functionality for managing bug reports in
> Savannah to even the general constraints of being a commercial
> open-source project.
>
> Still, I understand your problems are more important to you than the
> problems being faced by other users, I'd so appreciate if you'd give our
> bugzilla-based setup a chance at handling this bug. Or, let me
> know if you've already filed a report.

I'm not sure what Geoff's opinion on this is, but I don't think the 
issue has been in the bug reporting mechanism. It looks more like 
stability just wasn't deemed an important requirement until quite recently.

Gordan