You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "C. Scott Andreas (JIRA)" <ji...@apache.org> on 2018/11/19 05:58:01 UTC

[jira] [Updated] (CASSANDRA-8130) upgrade tests should run upgradesstables less eagerly

     [ https://issues.apache.org/jira/browse/CASSANDRA-8130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

C. Scott Andreas updated CASSANDRA-8130:
----------------------------------------
    Component/s: Testing

> upgrade tests should run upgradesstables less eagerly
> -----------------------------------------------------
>
>                 Key: CASSANDRA-8130
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8130
>             Project: Cassandra
>          Issue Type: Test
>          Components: Testing
>            Reporter: Russ Hatch
>            Priority: Major
>
> Currently the cassandra upgrade tests in cassandra-dtest are doing an upgrade then running upgradesstables soon after. We are missing some potential coverage with the current approach.
> Instead of upgrading sstables "early", we should be waiting until absolutely necessary to run upgradesstables to test the guarantee that a version can read sstables from the previous version. This will give tests more time to interact with reading previous version sstables and hopefully increase chances of catching a bug.
> Each version of cassandra should be able to read sstables from the previous version (so 2.1.x can read 2.0.x, but is not guaranteed to read 1.2.x), and therefore can work just fine reading and writing data. Writes of course will happen in the current sstable version, so old sstables may be supplanted by current ones over time (subject to write volume and compaction), potentially obviating the need for an sstable upgrade.
> upgradesstables must be run before upgrading when the system could contain sstables from two versions back since read compatibility is not guaranteed (so we must run upgradesstables before upgrading to 2.1.x if there is a chance that sstables still exist from 1.2.x; because this is two versions back).
> This is all a long-winded way of saying that we should keep track in the dtests if we are about to be 2 versions behind for an impending upgrade, and only run upgradesstables at that point.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org