You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Dinesh Bhat (JIRA)" <ji...@apache.org> on 2016/09/07 18:02:21 UTC
[jira] [Updated] (KUDU-1596) Automate upgrade/downgrade RC tests
[ https://issues.apache.org/jira/browse/KUDU-1596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dinesh Bhat updated KUDU-1596:
------------------------------
Description:
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.
- Black Box way of doing it:
./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.
was:
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.
Black Box way of doing it:
./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.
> 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.
> - Black Box way of doing it:
> ./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)