-
Story
-
Resolution: Done
-
Major
-
None
-
None
-
None
-
Product / Portfolio Work
-
False
-
-
False
-
8
-
None
-
uShift Sprint 248, uShift Sprint 249, uShift Sprint 250, uShift Sprint 251, uShift Sprint 252
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.
The goal of this spike is to investigate weather despite above rule, it would be possible to support direct EUS upgrade in this special case. The assumption is that there are not ectd schema migrations, its only about kublet and API service migrations. Also, we know that upstream k8s is working on supporting more version skew.
The idea of this spike is to invest a time boxed amout of time (e.g. 2-3 days of effort) to give it a try / analysis / thought.
Expected outcome is either: yes, thats worth a feature to create and pursue, or "no, stick to the current rules".
EUS customers would highly benefit from it. Only one upgrade step), esp. on ostree based deployments.