Russ Hatch created CASSANDRA-8130:
-------------------------------------
Summary: upgrade tests should run upgradesstables less eagerly
Key: CASSANDRA-8130
URL: https://issues.apache.org/jira/browse/CASSANDRA-8130
Project: Cassandra
Issue Type: Test
Reporter: Russ Hatch
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
(v6.3.4#6332)
