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 after.
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 many occasions. 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, Cos 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 [1] 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. > > Thanks, > Eli > > 1. http://wiki.apache.org/hadoop/HowToUseSystemTestFramework
signature.asc
Description: Digital signature