hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6201) HBase integration/system tests
Date Tue, 12 Jun 2012 22:53:42 GMT

    [ https://issues.apache.org/jira/browse/HBASE-6201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293981#comment-13293981

Enis Soztutar commented on HBASE-6201:

bq. Bigtop provides a framework for integration tests that is, essentially, 'mvn verify'.
Thanks for bringing this up. I know that bigtop provides a test framework for integration
tests. From my perspective, I see hbase and bigtop sharing responsibility on the testing side,
and we can work to define best practices for this, and would love to hear Bigtop's perspective
as well. 

I completely agree that HBase code, should not bother with deployments, cluster management
services, smoke testing, nor  integration with other components (hive, pig, etc). Those kind
of functionality can belong in BigTop or similar projects. 

However, some core testing functionality, is better managed by the HBase project. Lets consider
the TestMasterFailover test. Right now it is a unit test, testing the internal state transitions,
when the master fails. However, we can extend this test to run from the client side, and see
whether the transition is transparent when we kill the active master on an actual cluster.
That kind of testing, should be managed by HBase itself, because, although they would run
from the client side, these kind of tests are hbase-specific, and better managed by Hbase
devs. Also, I do not expect BigTop to host a large number of test cases for all of the stack
(right now 8 projects). 

Having said that, in this issue, we can come up with a way to interface with BigTop (and other
projects, custom jenkins jobs, etc) so that, these tests can use the underlying deployment,
server management, etc services, and BigTop, and others can just execute the HBase internal
integration tests on the cluster. A simple way for this is that HBase to offer {{mvn verify}}
to be consumed by BigTop, and those tests will use HBase's own scripts (and SSH, etc) for
cluster/server management. Since BigTop configures the cluster to be usable by those, it should
be ok.
> HBase integration/system tests
> ------------------------------
>                 Key: HBASE-6201
>                 URL: https://issues.apache.org/jira/browse/HBASE-6201
>             Project: HBase
>          Issue Type: Bug
>          Components: test
>    Affects Versions: 0.96.0
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
> Integration and general system tests have been discussed previously, and the conclusion
is that we need to unify how we do "release candidate" testing (HBASE-6091).
> In this issue, I would like to discuss and agree on a general plan, and open subtickets
for execution so that we can carry out most of the tests in HBASE-6091 automatically. 
> Initially, here is what I have in mind: 
> 1. Create hbase-it (or hbase-tests) containing forward port of HBASE-4454 (without any
tests). This will allow integration test to be run with
>  {code}
>   mvn verify
>  {code}
> 2. Add ability to run all integration/system tests on a given cluster. Smt like: 
>  {code}
>   mvn verify -Dconf=/etc/hbase/conf/
>  {code}
> should run the test suite on the given cluster. (Right now we can launch some of the
tests (TestAcidGuarantees) from command line). Most of the system tests will be client side,
and interface with the cluster through public APIs. We need a tool on top of MiniHBaseCluster
or improve HBaseTestingUtility, so that tests can interface with the mini cluster or the actual
cluster uniformly.
> 3. Port candidate unit tests to the integration tests module. Some of the candidates
>  - TestAcidGuarantees / TestAtomicOperation
>  - TestRegionBalancing (HBASE-6053)
>  - TestFullLogReconstruction
>  - TestMasterFailover
>  - TestImportExport
>  - TestMultiVersions / TestKeepDeletes
>  - TestFromClientSide
>  - TestShell and src/test/ruby
>  - TestRollingRestart
>  - Test**OnCluster
>  - Balancer tests
> These tests should continue to be run as unit tests w/o any change in semantics. However,
given an actual cluster, they should use that, instead of spinning a mini cluster.  
> 4. Add more tests, especially, long running ingestion tests (goraci, BigTop's TestLoadAndVerify,
LoadTestTool), and chaos monkey style fault tests. 
> All suggestions welcome. 

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message