[Gluster-devel] Performance Translators' Stability and Usefulness
Gordan Bobic
gordan at bobich.net
Sun Jul 5 17:01:17 UTC 2009
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
More information about the Gluster-devel
mailing list