Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 8 Dec 2014 06:28:13 +0000 (UTC)
From: "Dima Spivak (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12640894.1365117262000.97977.1418020093410@Atlassian.JIRA>
In-Reply-To: <JIRA.12640894.1365117262000@Atlassian.JIRA>
References: <JIRA.12640894.1365117262000@Atlassian.JIRA>
 <JIRA.12640894.1365117262181@arcas>
Subject: [jira] [Commented] (HBASE-8275) Tool to test binary compatibility
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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)