[
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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
