gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Mickey Mazarick
Subject: Re: [Gluster-devel] Performance Translators' Stability and Usefulness - Regression test outline
Date: Tue, 07 Jul 2009 15:31:16 -0400
User-agent: Thunderbird 2.0.0.22 (Windows/20090605)

Oh don't get me wrong I'm not ANTI-unit testing at all. I actually haven't had a server daemon crash since 1.4. I'm still leaving my cron jobs in. Try as I might I just don't care very much about the 1.5 gigs of memory the server process is using.

My point isn't to open up a who pragmatic vs perfection argument here.
We can't really write unit tests; it's going to be up to the developers. What we CAN come up with is a top down approach to testing our own setup and exposing integration problems which are going to be more of an issue for a project of this type. I would like to see some effort towards creating a unified way for us to do testing that will be meaningful and ensure stability for our given setup.

As to a logging translator how would that differ from the trace? Perhaps a more terse human-readable output.


-Mic


Gordan Bobic wrote:
On 07/07/2009 19:38, Mickey Mazarick wrote:

Since I'm running my setup as a storage farm it just doesn't matter to
me if there's a memory leak of if a server daemon crashes, I have cron
jobs that restart it and I barely take notice.

Ouch, ouch, ouch. That sounds like a monumental bodge. If somebody working for me implemented that kind of a "solution" for a frequently occuring problem in a production environment, they'd be finding themselves looking for a new job pretty quickly. Most likely along with the architect who trialed the solution before putting it into production without finding the problems that require such a solution. Solution to crashing processes is fixing the bug that causes them to crash, not a wrapper that gets them restarted.

True a regression testing
would get rid of the memory leak you hate but if they have to start from
the ground up I would rather encourage the dev team to add hotadd
upgrade and hotadd features. These things would keep my cluster going
even if there were catastrophic problems.

The _LAST_ thing Gluster needs at the moment is more features. Lack of stability loses you customers much faster than extra features gain them.

What I'm saying is that a good top down testing system is something we
can discuss here, spec out and perhaps create independently of the
development team. I think what most people want is a more stable product
and I think a top down approach will get it there faster than trying to
implement a given UT system from the bottom up. It will defiantly answer
the question "should I upgrade to this release?"

IMO, a top down approach merely glazes over the more fundamental problems. You cannot engineer quality from the top down. You design from top down, but quality comes from bottom up.

Gordan


_______________________________________________
Gluster-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/gluster-devel


--




reply via email to

[Prev in Thread] Current Thread [Next in Thread]