You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Mike Percy (JIRA)" <ji...@apache.org> on 2016/11/29 11:37:58 UTC

[jira] [Commented] (KUDU-1596) Automate upgrade/downgrade RC tests

    [ https://issues.apache.org/jira/browse/KUDU-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705037#comment-15705037 ] 

Mike Percy commented on KUDU-1596:
----------------------------------

Yeah this needs a longer writeup but the basic idea is this:

1. Start off with existing upgrade test infrastructure located @ https://github.com/apache/kudu/blob/master/src/kudu/integration-tests/version_migration-test.cc
2. Write a script that runs that "version migration test" across a matrix of desired migration paths
3. Extend the above so that we have a record of expected and actual results between versions. So we may say that we support rolling upgrades from 1.5 to 1.6 or something, but not 1.4 to 1.6, and the script can verify this.

I agree that we should use prebuilt binaries to verify these results because otherwise the tests would take a very long time to run.

> Automate upgrade/downgrade RC tests
> -----------------------------------
>
>                 Key: KUDU-1596
>                 URL: https://issues.apache.org/jira/browse/KUDU-1596
>             Project: Kudu
>          Issue Type: Task
>            Reporter: Dinesh Bhat
>            Assignee: Dinesh Bhat
>
> In discussion with [~mpercy] last week, we want to do the following to alleviate the  tedious/manual release upgrade/downgrade tests.
> - White box test cases, basic test to begin with.
> 1.  Create a table via external minicluster, say with 1.0 binaries
> 2. Load data and shutdown the cluster
> 3. SetBinarypath to new binaries(pre-existing location) carrying 1.1 version
> 4. Restart the cluster with same parameters, key thing is to stash the RPC/webutil addresses so that we can restart the respective servers on same ports again.
> 5. Add both negative and positive tests. Also need to see if we can induce an incompatible change by some means and test for negative cases.
> - One way of doing it in Black Box mode:
> #version_test.py --release 0.9.1 --dir=<path to bins> --release 0.10.0 --dir=<path to bins>
> # Download 0.9.1
> # Unpack/Build 0.9.1
> # Run test ./bin/run-version-itest 
> # Download 0.10.0
> # Unpack/Build 0.10.0
> # Run test ./bin/run-version-itest
> Need to think how to pass around RPC/web endpoints, and how to introduce negative tests for incompatible test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)