Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> 0.94 tests back in shape and some guidelines

Copy link to this message
Re: 0.94 tests back in shape and some guidelines
Generally I prefer to leave it up to good judgment as much as possibel rather than making hard rules.
There might be simple unittests that do not race.
I'm happy with a best effort approach. If a new test passes locally "a few times" and then passes on jenkins, or if it passes HadoopQA, that seems enough.
If it turns out to be flaky later we'll have to deal with that.
To make it easier we could also check in a script that runs a given test N times.
If we make it too onerous we'll see fewer contributions especially in the test area. :)
Another question I have: What do people think about a 0.94 HadoopQA? 0.94 and trunk are sufficiently different in many areas to maybe warrant that.
Not sure how this would work, though. How can we determine whether an attached patch file is for 0.94 or 0.96? Maybe by naming convention?
-- Lars

 From: Andrew Purtell <[EMAIL PROTECTED]>
Cc: lars hofhansl <[EMAIL PROTECTED]>
Sent: Wednesday, December 26, 2012 8:05 PM
Subject: Re: 0.94 tests back in shape and some guidelines
Hmm... How about just adding to the contributor section that new tests
should run reliably N times locally. N=10? N=20? N=100?
On Wed, Dec 26, 2012 at 12:02 PM, Enis Söztutar <[EMAIL PROTECTED]> wrote:

> Just a reference of some of the recent efforts that went in:
>     HBASE-7432 TestHBaseFsck prevents testsuite from finishing
>     HBASE-7431 TestSplitTransactionOnCluster tests still flaky
>     HBASE-7417 Test patch, hopefully fixes TestReplication
>     HBASE-7421 TestHFileCleaner->testHFileCleaning has an aggressive
> timeout
>     HBASE-7398 [0.94 UNIT TESTS] TestAssignmentManager fails frequently on
> CentOS 5
>     HBASE-7338 Fix flaky condition for
> org.apache.hadoop.hbase.TestRegionRebalancing.testRebalanceOnRegionServerNumberChange
>     HBASE-6175 TestFSUtils flaky on hdfs getFileStatus method
>     HBASE-7343 Fix flaky condition for TestDrainingServer (Himanshu)
>     HBASE-7301 Force ipv4 for unit tests
>     HBASE-7300  HbckTestingUtil needs to keep a static executor to lower
> the number of threads used
>     HBASE-6206 Large tests fail with jdk1.7
>     HBASE-7252 TestSizeBasedThrottler fails occasionally
>     HBASE-7235 TestMasterObserver is flaky
>     HBASE-7172 TestSplitLogManager.testVanishingTaskZNode() fails when run
> individually and is flaky
>     HBASE-7177 TestZooKeeperScanPolicyObserver.testScanPolicyObserver is
> flaky
>     HBASE-7166 TestSplitTransactionOnCluster tests are flaky
>     HBASE-7165 TestSplitLogManager.testUnassignedTimeout is flaky
>     HBASE-5984 TestLogRolling.testLogRollOnPipelineRestart failed with
> HADOOP 2.0.0
>     HBASE-7142 TestSplitLogManager#testDeadWorker may fail because of hard
> limit on the TimeoutMonitor's timeout period (Himanshu)
>     HBASE-7143 TestMetaMigrationRemovingHTD fails when used with Hadoop
> 0.23/2.x (Andrey Klochlov)
>     HBASE-6958 TestAssignmentManager sometimes fails
>     HBASE-6305 TestLocalHBaseCluster hangs with hadoop 2.0/0.23 builds.
> (Himanshu)
>     HBASE-6796 ADDENDUM, remove spurious time limit from testHFileCleaning
>     HBASE-6852, REVERT again, due to unexplained test failures that only
> occur on the jenkins machines
>     HBASE-7077 ADDENDUM, add TestCategory
>     HBASE-6733 TestReplication.queueFailover occasionally fails [Part-2]
>     HBASE-6906 TestHBaseFsck#testQuarantine* tests are flakey due to
> TestNotEnabledException
>     HBASE-6784 TestCoprocessorScanPolicy is sometimes flaky when run
> locally
>     HBASE-6714 TestMultiSlaveReplication#testMultiSlaveReplication may fail
>     HBASE-6715 TestFromClientSide.testCacheOnWriteEvictOnClose is flaky
> Please keep these in mind, when you are writing a new test.
> Enis
> On Wed, Dec 26, 2012 at 10:03 AM, Stack <[EMAIL PROTECTED]> wrote:
> > I just added a section to the 'contributing' section on committers being
> > responsible for ensuring contributor's patches do not break build or

Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)