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

Dinesh Bhat commented on KUDU-1596:
-----------------------------------

Sorry [~tlipcon], my JIRA email filters are really basic, so I miss out on 
important notifications at times coming from JIRA domain. version_test.py above 
doesn't have a good naming, but at high level it would execute everything from 
begin to end. i.e, 
 - building the binaries (given the release version, git clone from weblink)
 - execute set of tests from the built path
 - build binaries from other release bits(newer or older)
 - restart the masters/tservers from new path(keeping the same FS layout, RPC 
endpoints), and then execute the tests again.

And yeah, I didn't think of el6/s3 specifically, but it's a good point, that 
way we don't have too much dependency on other OS specific build tools. 
However, I may be missing few finer details at this point. Do you see any 
challenges with above or do you think it's not that useful ? I also did not 
understand the scope of coverage when you said 'full platform coverage' in 
above comment.



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

Reply via email to