-Re: System tests on 0.20.20x releases
Konstantin Boudnik 2011-08-22, 04:34
System tests (Herriot controlled) tests were a part of nightly testing of every
build for at least 2 of .2xx release. I really can not comment on .203 and
A normal procedure was to build a normal bits and run the tests; build
instrumented bits, deploy them to a 10 nodes cluster, and run system tests.
The current state of the code is that system tests require source code
workspace to be executed from. I have done some initial work to do workspace
independent testing but I don't know if it has been included to the public
releases of .203+ - I haven't really checked.
At any rate, running system tests are an easy task and the wiki page is
explaining how to do it. Assembling an instrumented cluster on the other hand
requires certain knowledge and release process and bits production.
Instrumented cluster isn't fault-injected - it is just instrumented ;) Yes, it
contains a few extra helper API calls in a few classes, which exactly makes
them a way more useful for the testing purpose. Without those a number of
testing scenarios would be impossible to implement as I have explained it on
For the regular runs of system test Roman and I have created a regular
deployment of 0.22 cluster builds under Apache Hudson control a few months
ago. I don't know what's going on with this testing after recent troubles with
the build machines.
Hope it helps,
On Fri, Aug 19, 2011 at 05:29PM, Eli Collins wrote:
> Has anyone tried running the system tests on a 0.20.20x release? Why
> don't we run these via Hudson?
> After following the instructions on the wiki  and making a bunch of
> additional fixes (setting dfs.datanode.ipc.address in the config,
> using sbin instead of bin, copying libs into the FI build lib dir,
> etc) I was able to get the tests running however the tests seem to
> have bitrot.
> The reason I ask is that it looks like the src/test/system tests are
> only compiled or run via the test-system target and it doesn't look
> like Hudson or developers use that target, therefore we're not doing
> anything to prevent people from breaking the tests. I tried to run
> them to see if one of my changes would break them but I can't imagine
> most people will jump through all the above hoops.
> On a related note, is there any way to run these against an existing
> build/cluster? It looks like they require running on a build that's
> been fault injected (ie they use custom protocol classes that are not
> present in the normal tarball) which makes them much less useful.
> 1. http://wiki.apache.org/hadoop/HowToUseSystemTestFramework