Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Fri, 4 Sep 2015 16:30:46 +0000 (UTC)
From: "Jim Witschey (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12861872.1441382074000.258424.1441384246294@Atlassian.JIRA>
In-Reply-To: <JIRA.12861872.1441382074000@Atlassian.JIRA>
References: <JIRA.12861872.1441382074000@Atlassian.JIRA>
 <JIRA.12861872.1441382074248@arcas>
Subject: [jira] [Commented] (CASSANDRA-10269) Run new upgrade tests on
 supported upgrade paths
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jim Witschey commented on CASSANDRA-10269:
------------------------------------------

.bq these are primarily pre to post 8099 tests, so I dont see the point of 3.0 being the old version.

That's a good point -- [~thobbs] [~iamaleksey] thoughts? If these are general upgrade-path tests, then 3.0 -> trunk is important, but if these are specific to the new storage engine, I agree with Philip.

.bq I'm fine with only running one on user branches, but if we move these to a separate job, then they wont be running on user branches, since those only run the normal dtest job.

Running only one of the upgrade paths on dev jobs sounds reasonable, as long as trunk is still pre-3.0 -- perhaps we run 2.1 -> HEAD on those branches. I agree that the impact on job time will be small.

> Run new upgrade tests on supported upgrade paths
> ------------------------------------------------
>
>                 Key: CASSANDRA-10269
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10269
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tests
>            Reporter: Jim Witschey
>            Assignee: Jim Witschey
>
> The upgrade dtests for 8099 backwards compatibility (originally dealt with in [this dtest PR|https://github.com/riptano/cassandra-dtest/pull/471] and [this JIRA ticket|https://issues.apache.org/jira/browse/CASSANDRA-9893]) need to be run with upgrades over the following upgrade paths:
> - 2.1 -> 3.0
> - 2.2 -> 3.0
> - 3.0 -> trunk
> There are a number of ways we could manage this. We could run the tests as part of the normal dtest jobs in 2.1, 2.2, and 3.0, and select what version to upgrade to based on the version of the test. We could also refactor the new upgrade tests to use the upgrade machinery in the existing upgrade tests.
> [~philipthompson] [~rhatch] Do you have opinions? Can you think of other options?


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