feature(rolling-upgrades): update the base versions rules #11959

fruch · 2025-09-14T12:13:52Z

now that we have at least 4 short terms versions a year, we should now support upgrade from any of the STS version up to the last LTS version.

this gonna make the matrix more complex as we have more version between every LTS version

Testing

🟢 https://jenkins.scylladb.com/job/scylla-staging/job/fruch/job/rolling-upgrade-ubuntu2404-test/13/pipeline-overview/ (master)
🟢 : https://jenkins.scylladb.com/job/scylla-staging/job/fruch/job/rolling-upgrade-ubuntu2404-test/14/pipeline-overview/ (upgrade to release 2025.4)

PR pre-checks (self review)

I added the relevant backport labels
I didn't leave commented-out/debugging code

Reminders

Add New configuration option and document them (in sdcm/sct_config.py)
Add unit tests to cover my changes (under unit-test/ folder)
Update the Readme/doc folder relevant to this change (if needed)

Copilot

Pull Request Overview

This PR updates the rolling upgrade base version rules to support upgrades from any Short Term Support (STS) version up to the last Long Term Support (LTS) version, accommodating the increased release frequency of 4+ STS versions per year.

Key changes:

Modified upgrade logic for STS versions to include all STS versions since the last LTS plus the LTS version itself
Updated master branch upgrade logic to only upgrade from the last LTS version
Added comprehensive test coverage for the new upgrade scenarios

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
utils/get_supported_scylla_base_versions.py	Implements new upgrade matrix logic for STS and LTS versions with more comprehensive version support
unit_tests/test_base_version.py	Adds test cases to verify the new upgrade behavior for 2025.3 and 2025.4 releases

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

unit_tests/test_base_version.py

fruch · 2025-09-14T12:17:13Z

@mykaul FYI, it means that for 2025.3, we have extra test for each rolling upgrade case, and for 2025.4, 2 extra tests for each case.

unit_tests/test_base_version.py

mykaul · 2025-09-14T12:29:02Z

utils/get_supported_scylla_base_versions.py

-                             if lts_version.search(_version)), None))
-                else:
-                    LOGGER.warning('version format not the default - %s', version)
+            lts_version = re.compile(r'\d{4}\.1')  # lts = long term support


General Q for the code below? Isn't it easier to just build the matrix - initial source, all the way to the latest?
Something like (in the future, showing 2026.1):

2024.1, 2025.1, 2025.2, 2025.3, 2025.4, 2026.1
2024.1, 2025.1, 2026.1

Where the matrix is going over every 'run' above and starts from each slot - all the way to the end?
For example with the above:
2024.1, 2025.1, 2025.2, 2025.3, 2025.4, 2026.1
2025.1, 2025.2, 2025.3, 2025.4, 2026.1
2025.2, 2025.3, 2025.4, 2026.1
2025.3, 2025.4, 2026.1
2025.4, 2026.1

2024.1, 2025.1, 2026.1
2025.1, 2026.1

I'm not sure I'm following what is the suggestion, the end result is that we should support one last LTS version and all the versions in between.

In 2026.1 we still would want to update from the 4 versions before it ? That would mean 5 variants once the first release is out ...

@mykaul you are missing how the tests are working, it's 1 to 1 upgrades, we are not doing continues upgrades like you are assuming...

target_version=2026.1
bases_vesrions=2025.1,2025.4

means we upgrade from 2025.1 to 2026.1, and in different run from 2025.4 to 2026.1

What could be easier is to just list the LTS versions instead of assuming them from their suffix.
Right now we don’t have a way to mark a version to be LTS or test it like LTS.

how can we list them not based on their suffix ?

Anyhow giving 2026.1 as example, but are the base version we should test for it

"2025.1", "2025.4", "2026.1" (if current is LTS, last LTS and last STS)
"2025.1", "2025.2", "2025.3", "2025.4", "2026.1" (Last LTS and All STS since)

Having somewhere a list of versions, like:
LTS = {"2023.1", "2024.1",...}

Or we can have a list of dictionaries with all supported versions and each if it's STS or LTS.

And then we need to keep those update all the time,

it worked so great in dtest, so we should repeat it here ?

unit_tests/test_base_version.py

utils/get_supported_scylla_base_versions.py

roydahan · 2025-09-17T09:01:57Z

utils/get_supported_scylla_base_versions.py

        elif version == "master":
-            # add 2 last enterprise versions, since one of them might be only rc version, and we'll need to filter it out
-            source_available_base_version.extend(source_available_release_list[-2:])
+            # For master branch, upgrade only from last LTS version


Don’t we test also last source available version (e.g last STS if it’s not LTS)?

in master we always test only one version, which one it should be, is a good question

we did agreed that if we enable so many base version for release, we should do last version and last LTS for master runs

fruch · 2025-10-12T06:03:38Z

@roydahan any luck with changing this requirement ? (since 2025.4 is branched, and we don't have it in yet...)

fruch · 2025-10-16T09:28:48Z

@roydahan any luck with changing this requirement ? (since 2025.4 is branched, and we don't have it in yet...)

@roydahan ping ?

roydahan · 2025-10-20T14:55:59Z

Discussion is on the test plan.

now that we have at least 4 short terms versions a year, we should now support upgrade from any of the STS version up to the last LTS version. this gonna make the matrix more complex as we have more version between every LTS version

fruch · 2025-10-22T15:01:54Z

@roydahan @mykaul

to sum it up

we have a flag
on releases, would make a job upgrade from all STS version up to last LTS (see the unittest for examples)
on master it would update to last LTS and last STS (one or two versions)

we gonna enable new flag on two test:

AMI based (heavy test 4-5h)
centos based test (now cent-9, I'll replace it with rocky10 in a different PR)

so now we'll be cover one of our SMI (debian based), and one centos/rhel style

I think that would be enough for initial support, later we can extend it.

roydahan · 2025-10-23T13:43:51Z

Sounds good to me.

fruch requested review from a team and Copilot September 14, 2025 12:13

fruch added the test-integration Enable running the integration tests suite label Sep 14, 2025

github-actions bot assigned fruch Sep 14, 2025

Copilot AI reviewed Sep 14, 2025

View reviewed changes

unit_tests/test_base_version.py Outdated Show resolved Hide resolved

fruch requested review from mykaul, roydahan and tzach September 14, 2025 12:14

fruch added the backport/2025.3 label Sep 14, 2025

mykaul reviewed Sep 14, 2025

View reviewed changes

unit_tests/test_base_version.py Outdated Show resolved Hide resolved

mykaul reviewed Sep 14, 2025

View reviewed changes

vponomaryov reviewed Sep 16, 2025

View reviewed changes

unit_tests/test_base_version.py Outdated Show resolved Hide resolved

utils/get_supported_scylla_base_versions.py Show resolved Hide resolved

fruch force-pushed the update_upgrade_base_version_rules branch 2 times, most recently from ffad66e to 18c868e Compare September 17, 2025 06:36

roydahan reviewed Sep 17, 2025

View reviewed changes

fruch force-pushed the update_upgrade_base_version_rules branch from 18c868e to ceb95de Compare September 17, 2025 13:12

fruch force-pushed the update_upgrade_base_version_rules branch 2 times, most recently from a8ee8b8 to b9f9f6e Compare September 25, 2025 11:25

scylladbbot added the backport/2025.4 label Sep 30, 2025

fruch removed the backport/2025.3 label Oct 16, 2025

fruch force-pushed the update_upgrade_base_version_rules branch from b9f9f6e to c940be3 Compare October 20, 2025 16:03

fruch mentioned this pull request Oct 20, 2025

Add upgrade configurations for 2025.1,2025.2 and 2025.3 to 2025.4 #12245

Open

fruch force-pushed the update_upgrade_base_version_rules branch 4 times, most recently from e455fb9 to d8d38c8 Compare October 21, 2025 10:40

fruch force-pushed the update_upgrade_base_version_rules branch from d8d38c8 to 3179153 Compare October 21, 2025 11:21

fruch force-pushed the update_upgrade_base_version_rules branch from 3179153 to a24db5e Compare October 21, 2025 20:22

fruch requested review from mykaul and roydahan October 22, 2025 15:02

roydahan approved these changes Oct 23, 2025

View reviewed changes

fruch merged commit 9434f48 into scylladb:master Oct 23, 2025
8 checks passed

scylladbbot added the promoted-to-master label Oct 23, 2025

scylladbbot mentioned this pull request Oct 23, 2025

[Backport 2025.4] feature(rolling-upgrades): update the base versions rules #12301

Open

4 tasks

feature(rolling-upgrades): update the base versions rules #11959

feature(rolling-upgrades): update the base versions rules #11959

Uh oh!

Conversation

fruch commented Sep 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Testing

PR pre-checks (self review)

Reminders

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Uh oh!

fruch commented Sep 14, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

roydahan Sep 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fruch commented Oct 12, 2025

Uh oh!

fruch commented Oct 16, 2025

Uh oh!

roydahan commented Oct 20, 2025

Uh oh!

fruch commented Oct 22, 2025

Uh oh!

roydahan commented Oct 23, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

fruch commented Sep 14, 2025 •

edited

Loading

roydahan Sep 17, 2025 •

edited

Loading