[
https://issues.apache.org/jira/browse/HBASE-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gautam updated HBASE-8928:
--------------------------
Description:
Let me split this requirement into 2 parts:
i) ChaosMonkey
I was trying to add more tests around new actions and policies by leveraging
the existing classes nested inside ChaosMonkey.
But it turned out that some of the classes cannot be used outside, unless we
make those visible to the world.
Here is an example:
I cannot extend ChaosMonkey.Action, as the init(ActionContext context) method
has package-wide visibility.
There are other places as well which makes it impossible for anyone to extend
on top of this hierarchy.
ii) LoadTestTool
I wanted to extend this tool to define failure/pass criteria based on % of
read/write failed, rather than comparing against absolute 0.
For that this beautiful class should mark some of its properties usable by its
child, by marking those protected.
I wanted to get unblocked here first.
Once this gets fixed, I think I can take up a JIRA item to refactor these tools.
was:
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 are:
- 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.
> Make ChaosMonkey & LoadTest tools extensible, to allow addition of more
> actions and policies.
> ---------------------------------------------------------------------------------------------
>
> Key: HBASE-8928
> URL: https://issues.apache.org/jira/browse/HBASE-8928
> Project: HBase
> Issue Type: Bug
> Components: test
> Affects Versions: 0.95.2
> Reporter: gautam
> Assignee: Enis Soztutar
>
> Let me split this requirement into 2 parts:
> i) ChaosMonkey
> I was trying to add more tests around new actions and policies by leveraging
> the existing classes nested inside ChaosMonkey.
> But it turned out that some of the classes cannot be used outside, unless we
> make those visible to the world.
> Here is an example:
> I cannot extend ChaosMonkey.Action, as the init(ActionContext context) method
> has package-wide visibility.
> There are other places as well which makes it impossible for anyone to extend
> on top of this hierarchy.
> ii) LoadTestTool
> I wanted to extend this tool to define failure/pass criteria based on % of
> read/write failed, rather than comparing against absolute 0.
> For that this beautiful class should mark some of its properties usable by
> its child, by marking those protected.
> I wanted to get unblocked here first.
> Once this gets fixed, I think I can take up a JIRA item to refactor these
> tools.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
