[
https://issues.apache.org/jira/browse/HDDS-15937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siyao Meng updated HDDS-15937:
------------------------------
Description:
h3. Goal
Verify that Ozone 2.2.0 with RocksDB 7.7.3 can reopen and read the same OM
database after Ozone 2.3.0 with RocksDB 10.10.1.1 has written and compacted new
SST files. The new SSTs must remain at block-based table format_version 5 so
rollback to 2.2.0 remains compatible.
h3. Test command
{code}
run_test ha non-rolling-upgrade 2.2.0 2.3.0
{code}
h3. Test scenario
# Start the HA cluster on Ozone 2.2.0, verify it is finalized, and create the
baseline upgrade dataset.
# Restart the same cluster and data directories on Ozone 2.3.0 with --upgrade.
Do not invoke the explicit finalization step before downgrade. Since 2.3.0
introduces no new OM or HDDS layout feature after 2.2.0, OM and SCM already
report finalized; this exercises rollback across the binary and RocksDB version
change rather than rollback with a pending layout finalization.
# While running 2.3.0, create a dedicated OBS volume and bucket and perform
three rounds of writes. Each round writes 2,000 keys and forces keyTable
compaction on om1, om2, and om3. Inventory newly created SST files, copy them
to the test results, inspect their table properties, and require format_version
5. Require at least one newly created OM SST. Newly observed SCM and datanode
SSTs are checked opportunistically.
# Stop 2.3.0 and restart the same data directories on Ozone 2.2.0 with
--downgrade. Validate the common datasets written under 2.3.0 and read
format-round-3/0, written during the final 2.3.0 compaction round. Require the
downloaded key to be non-empty.
# Restart 2.3.0, run the normal explicit finalization phase, and complete the
common upgrade validations.
h3. Success criteria
* Compaction completes successfully on all three OMs in all three rounds.
* Every newly observed SST reports format_version 5.
* At least one new OM SST is observed.
* Ozone 2.2.0 with RocksDB 7.7.3 starts successfully against the database
previously used by 2.3.0.
* The downgraded 2.2.0 cluster reads both the normal upgrade datasets and
format-round-3/0.
* The complete HA non-rolling-upgrade test passes.
h3. Evidence from the ad-hoc validation
* Nine new OM SST files were observed across three compaction rounds; all
reported format_version 5.
* After downgrade, Ozone 2.2.0 successfully read format-round-3/0.
* The complete Robot Framework run finished with 77 passed, 0 failed.
h3. Proof boundary
This is an end-to-end database reopen and data-read test: RocksDB 7.7.3 starts
against the same database after RocksDB 10.10.1.1 wrote and compacted SSTs,
then serves data written by 2.3.0. The format inspector reads each copied SST
with RocksDB 10.10.1.1 to verify format_version 5. The test does not separately
open every copied SST with RocksDB 7.7.3, and it does not map format-round-3/0
to one specific inspected SST.
was:TBD
> Verify RocksDB 7.7.3 in 2.2.0 can reopen the database after RocksDB 10.10.1.1
> wrote and compacted SSTs
> ------------------------------------------------------------------------------------------------------
>
> Key: HDDS-15937
> URL: https://issues.apache.org/jira/browse/HDDS-15937
> Project: Apache Ozone
> Issue Type: Sub-task
> Components: test
> Reporter: Siyao Meng
> Assignee: Siyao Meng
> Priority: Major
>
> h3. Goal
> Verify that Ozone 2.2.0 with RocksDB 7.7.3 can reopen and read the same OM
> database after Ozone 2.3.0 with RocksDB 10.10.1.1 has written and compacted
> new SST files. The new SSTs must remain at block-based table format_version 5
> so rollback to 2.2.0 remains compatible.
> h3. Test command
> {code}
> run_test ha non-rolling-upgrade 2.2.0 2.3.0
> {code}
> h3. Test scenario
> # Start the HA cluster on Ozone 2.2.0, verify it is finalized, and create the
> baseline upgrade dataset.
> # Restart the same cluster and data directories on Ozone 2.3.0 with
> --upgrade. Do not invoke the explicit finalization step before downgrade.
> Since 2.3.0 introduces no new OM or HDDS layout feature after 2.2.0, OM and
> SCM already report finalized; this exercises rollback across the binary and
> RocksDB version change rather than rollback with a pending layout
> finalization.
> # While running 2.3.0, create a dedicated OBS volume and bucket and perform
> three rounds of writes. Each round writes 2,000 keys and forces keyTable
> compaction on om1, om2, and om3. Inventory newly created SST files, copy them
> to the test results, inspect their table properties, and require
> format_version 5. Require at least one newly created OM SST. Newly observed
> SCM and datanode SSTs are checked opportunistically.
> # Stop 2.3.0 and restart the same data directories on Ozone 2.2.0 with
> --downgrade. Validate the common datasets written under 2.3.0 and read
> format-round-3/0, written during the final 2.3.0 compaction round. Require
> the downloaded key to be non-empty.
> # Restart 2.3.0, run the normal explicit finalization phase, and complete the
> common upgrade validations.
> h3. Success criteria
> * Compaction completes successfully on all three OMs in all three rounds.
> * Every newly observed SST reports format_version 5.
> * At least one new OM SST is observed.
> * Ozone 2.2.0 with RocksDB 7.7.3 starts successfully against the database
> previously used by 2.3.0.
> * The downgraded 2.2.0 cluster reads both the normal upgrade datasets and
> format-round-3/0.
> * The complete HA non-rolling-upgrade test passes.
> h3. Evidence from the ad-hoc validation
> * Nine new OM SST files were observed across three compaction rounds; all
> reported format_version 5.
> * After downgrade, Ozone 2.2.0 successfully read format-round-3/0.
> * The complete Robot Framework run finished with 77 passed, 0 failed.
> h3. Proof boundary
> This is an end-to-end database reopen and data-read test: RocksDB 7.7.3
> starts against the same database after RocksDB 10.10.1.1 wrote and compacted
> SSTs, then serves data written by 2.3.0. The format inspector reads each
> copied SST with RocksDB 10.10.1.1 to verify format_version 5. The test does
> not separately open every copied SST with RocksDB 7.7.3, and it does not map
> format-round-3/0 to one specific inspected SST.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
