[
https://issues.apache.org/jira/browse/HBASE-8275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14237502#comment-14237502
]
Dima Spivak commented on HBASE-8275:
------------------------------------
I think we have a pretty decent solution to address this that we're using at
Cloudera, and which I'd love to push upstream. The workflow looks like this:
- Store pre-created Docker images in a common registry containing the various
releases of HBase servers we want to test against. This would just be an
extension of the functionality we already have under /dev-support/hbase_docker.
(Also, the gents at Apache Infra are working on the registry aspect at
INFRA-8441.)
- Also store images of HBase clients (again, for each version we want to test).
These images contain basic dependencies (e.g. Java, Maven) and some client code
to exercise as much of the API as possible. At Cloudera, what I've found has
worked very well for this is TestFromClientSide, so I extend this into another
class (TestJavaClient) and override the unit test-specific aspects of it in the
derived class (e.g. prevent starting a minicluster, and skipping a few tests
that touch HBase internals). {{mvn compile}} is used to pre-compile the source
code for the original version and then the whole deal is committed into a
Docker image. The client image also has POM files for any other version of
HBase for which we want to test binary compatibility.
- With the images precreated, running a test of compatibility is done by
standing up an HBase cluster (again, using the Docker images), and then using
the HBase client image and a simple script to test either wire or binary
compatibility. For wire compatibility, we use {{mvn verify}}, which takes the
already-compiled source code alongside the original version of JARs and points
it at the HBase server. For binary compatibility, the script handles pointing
Maven at the pom.xml referencing the JARs I care to validate against, and then
a simple {{mvn failsafe:integration-test failsafe:verify}} doesn't recompile
the code, but puts the new binaries on the classpath and tries running against
the server.
> Tool to test binary compatibility
> ---------------------------------
>
> Key: HBASE-8275
> URL: https://issues.apache.org/jira/browse/HBASE-8275
> Project: HBase
> Issue Type: New Feature
> Reporter: Jean-Daniel Cryans
>
> Stack and I were discussing of ways to make binary compatibility easier to
> test than doing it completely by hand.
> One idea would be to have a tool that uses reflection to generate code that
> calls all the public methods from a list of classes. You would then compile
> this code against the current version you are on, then try it out with
> different HBase jars without recompiling.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
