Details
-
Feature
-
Resolution: Done
-
Normal
-
openshift-4.16
-
False
-
-
False
-
-
32
-
32%
-
-
Feature
-
S
-
0
-
0
Description
Feature Overview (aka. Goal Summary)
With V4.16, we have our first EUS->EUS upgrade, i.e. from V4.14 to V4.16.
In the initial upgrade design, we agreed and prohibited version skip upgrades. We have determined skipping versions is safe, at least for now, and so we want to extend the upgrade path to support updating from Y-2 version at a time.
EUS customers would highly benefit from it. Only one upgrade step, esp. on ostree based deployments.
Goals (aka. expected user outcomes)
Support updating MicroShift from 4.y-2 to 4.y in place without installing 4.y-1. We anticipate that being used most often for EUS to EUS upgrades, but the implementation should not be limited to even version number releases.
Requirements (aka. Acceptance Criteria):
Full support of in place upgrades from Y-2 to Y version without recreating the etcd database from scratch, with a single re-start (rpm) / re-boot (ostree) of MicroShift.
| Deployment considerations | List applicable specific needs (N/A = not applicable) |
| Self-managed, managed, or both | N/A |
| Classic (standalone cluster) | N/A |
| Hosted control planes | N/A |
| Multi node, Compact (three node), or Single node (SNO), or all | N/A |
| Connected / Restricted Network | Yes |
| Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x) | Yes |
| Operator compatibility | N/A |
| Backport needed (list applicable versions) | N/A |
| UI need (e.g. OpenShift Console, dynamic plugin, OCM) | N/A |
| Other (please specify) | MicroShift |
Use Cases (Optional):
RPM-based and ostree based upgrades.
Questions to Answer (Optional):
none
Out of Scope
Operators and user workloads are out of scope.
Upgrading more than 2 versions at a time is out of scope to help us constrain the test matrix.
Background
n/a
Customer Considerations
We anticipate MicroShift customers to go to production on EUS versions only, even more so than OpenShift customers.
Documentation Considerations
We will need to ensure that any guidance given about updating one version at a time is updated to reflect that we can now update 2 versions at a time. This mainly concerns the release compatibility matrix in the Updating book (1.1.2) and the update path 1.1.3.
The v
Interoperability Considerations
Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact? What interoperability test scenarios should be factored by the layered products? Initial completion during Refinement status.
<your text here>
Attachments
Issue Links
- links to
