[Gluster-users] gluster 3.2.0 - totally broken?

[Jeff Darcy]

On 05/18/2011 11:09 AM, Burnash, James wrote:
> Based on my experiences so far, I would absolutely agree with you.
> 
> I know new releases are hard to produce at 100% coming out of the
> gate, so the fact that 3.2 is not all that robust is unsurprising to
> me. Hopefully the point releases improve this.
> 
> I would really like to see the known bugs in 3.1.4 fixed in a later
> point release in that branch.
> 
> I do agree slightly with Stephan (which is unusual) that features
> over stability seems to be the current direction for the project. The
> shame of that is that stability has got to be the #1 priority for any
> features to be useful. That said, 3.1.3 does seem pretty solid to me
> now, compared with 3.1.1 and with 3.0.4.
> 
> I disagree with Stephan about everything after 2.0.9 being "bogus".
> Just because the development direction does not correspond with a
> single individuals needs doesn't mean it's worthless or "totally
> broken" for others. The additional features for non-downtime changes
> to the storage nodes are very useful to us here - though more robust
> behavior and better documentation would be welcome.

As the leader for a project based on GlusterFS, I'm also very sensitive
to the stability issue. It is a bit disappointing when every major
release seems to be marked by significant regressions in existing
functionality. It's particular worrying when even community leaders and
distro packagers report serious problems and those take a long time to
resolve. I'd put you in that category, James, along with JoeJulian and
daMaestro just with respect to the 3.1.4 and 3.2 releases. Free or paid,
that's not a nice thing to do to your marquee users, and you're the kind
of people whose interest and support we can hardly afford to lose.  Even
I've been forced to take a second look at alternatives, and I'm just
about the biggest booster Gluster has who's not on their payroll.

So how do we deal with these issues *constructively*? Not by
characterizing every release since 2.0.9 as "bogus" that's for sure.
Sorry, Stephan, but that's absurd. The 3.1+ versions are not only more
manageable and add the non-disruptive configuration changes that James
mentions (*very* hard to do BTW), but there have also been significant
fixes to just about every area of the code. I see 284 high-severity bugs
whose resolution went to FIXED in the past year. Granted, some of those
were *introduced* in the past year, but the majority can easily be seen
to have existed in 2.0.9 or its predecessors and there are many more
that wouldn't have shown up on that search due to inconsistent use of
the bug system (I'll get to that in a moment). That's a lot of bugs that
definitely did affect someone, even if it wasn't you, especially since
storage and distributed systems are not the easiest programming domains
to work in. Watch the bug list or the patch stream closely, as I do, and
you'll see a constant stream of fixes to bugs that have clearly been
latent since 2.0.9 or earlier.

The problem I do see, and I do agree with others who've spoken out here,
is primarily one of communication. It's a bit frustrating to see dozens
of geosync/marker/quota patches fly by while a report of a serious bug
isn't even *assigned* (let alone worked on as far as anyone can tell)
for days or even weeks. I can only imagine how it must be for the people
whose filesystems have been totally down for that long, whose bosses are
breathing down their necks and pointedly suggesting that a technology
switch might be in order. We can all help by making sure our bugs are
actually filed on bugs.gluster.com - not just mentioned here or on IRC -
and by doing our part to provide the developers with the information
they need to reproduce or fix problems. We can help by actually testing
pre-release versions, particularly if our configurations/workloads are
likely to represent known gaps in Gluster's own test coverage. The devs
can help by marking bugs' status/assignment, severity/priority, and
found/fixed versions more consistently. The regression patterns in the
last few releases clearly indicate that more tests are needed in certain
areas such as RDMA and upgrades with existing data.

The key here is that if we want things to change we all need to make it
happen. We can't tell Gluster how to run their business, which includes
how they decide on features or how they allocate resources to new
features vs. bug fixes, but as a community we can give them clear and
unambiguous information about what is holding back more widespread
adoption. It used to be manageability; now it's bugs. We need to be as
specific as we possibly can about which bugs or shortcomings matter to
us, not just vague "it doesn't work" or "it's slow" or "it's not POSIX
enough" kinds of stuff, so that a concrete plan can be made to improve
the situation.