CI: test operations on a Sylva v(n-1) workload cluster on a Sylva v(n) mgmt cluster
After an upgrade of a Sylva mgmt cluster from version (n) to (n+1) or (n+2), we would like to be able to do operations on a workload cluster that hasn't been upgraded and is still in version (n): updating kubernetes, doing node additions, enabling units, etc.
In previous versions of Sylva, we had design/code constraints, and some CAPI provider corner cases, that were making it impossible to support that, because of implicit dependencies (e.g. some adherence of sylva-capi-cluster to some provider version, or coupling related to "shared settings" refactoring, or stuff related to OS images management for capm3).
I believe that these limitations are behind us today (progressing this issue will be the opportunity to confirm this belief).
So we should introduce CI pipelines that would:
- deploy Sylva version (n) -- both a wkld cluster and a mgmt cluster
- upgrade mgmt cluster to Sylva (n+1)
- remaining on Sylva (n), do a Kubernetes minor version upgrade (this is the most ambitious; it this works, all simpler scenarios would work as well)
baremetal workload clusters vs openstack clusters
For openstack cluster, nothing particular should be needed.
For baremetal workload clusters, the test will need to leverage the work done in !6005 (merged) (#1942 (closed)): tweak os_image_server_additional_selectors in the CI deployment values used for the CI pipelines specific to this test, so that old Sylva OS images are served.