vladzcloudius
commented
1 year ago New in v3:
- Fixed things that made the molecule fail.
- Only fetch latest version when 'online' install type is used.
- Error out when 'latest' version is requested for a non-online installation.
New in v4:
- Split the large patch into "refactoring" and "new feature" patches.
- Changed the order of patches: moved the "scylla-node: Debian: filter out RCs when looking for a full version name" to be the first one in the series.
New in v5:
- Improved the "installed scylla version check" on RH after testing the PR with CentOS-Stream-8: implemented it using yum module to support short and long version names in
scylla_version.
Both Ubuntu and RH manual testing included:
1) Install the 2 nodes cluster with 2022.2.6 with a vanilla Role.
2) Run the Role from the PR: should succeed.
3) Set scylla_version: 2022.2.11 and run the Role from the PR: should fail on a scylla version check.
4) Run as (3) but also set skip_installed_scylla_version_check: True: should succeed and scylla version installed remain 2022.2.6.
5) Decommission one of the nodes and remove all scylla packages from it.
6) Run the Role the same way as in (4): should succeed and install 2022.2.11 on the node from (5).
7) Set scylla_version: latest and validate that the Role is capable to identify what's the latest scylla version to date: run this test with scylla_edition: oss and with scylla_edition: enterprise.
tarzanek
Scylla should only be upgraded via the corresponding 'upgrade' flow. Other than that the Role should only install binaries if they haven't been installed yet.
If they have already been installed but the version differs from the one specified via 'scylla_version' Role will error out by default.
The Operator may decide to skip the check above using 'skip_installed_scylla_version_check'.