-
Outcome
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
14% To Do, 14% In Progress, 71% Done
-
False
-
Feature Overview (aka. Goal Summary)
Improve customer experience in OCP updates. Identify and Remove commonly raised confusing terms from UX and docs.
Separate EUS-to-EUS update feature from EUS channel. EUS channel is only for 3 year lifecycle tracking.
Note: This feature was initially created to Rename some of the OpenShift update channels to address customer misunderstanding of existing OpenShift update channel names.But that effort was shelved. Another idea was to create a single channel, but was put on hold until 4.20.
This feature covers the other efforts around EUS channel, EUS-to-EUS updates and supporting control-plane only updates in
Goals (aka. expected user outcomes)
rename candidate: no change[proposal Rejected]Fast channel gets renamed to GA-channel[proposal Rejected]Stable channel gets renamed to fleet-approved[proposal Rejected]- EUS channel will be the only channel which receives z-stream updates after 18 months. 3 year lifecycle change.
- Reposition "Supported but not recommended" as “Known Issues”, remove from UX and CLI
- EUS-to-EUS updates gets renamed to → Control Plane Only update
- Document change
- All channels should offer multiple version updates within OpenShift's allowable Kubelet version skew for that version
- Implement Control Plane and Worker Plane updates
- Support n-3 skew
- offer multiple version updates within OpenShift's allowable Kubelet version skew for that version
Requirements (aka. Acceptance Criteria):
- The OpenShift update channels will be updated to reflect the label changes and any backend required changes to address the label changes.
- UI updates will be needed.
- Docs will be updated.
Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed. Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.
Deployment considerations | List applicable specific needs (N/A = not applicable) |
Self-managed, managed, or both | Both |
Classic (standalone cluster) | Applicable to classic standalone clusters |
Hosted control planes | Applicable to HCP |
Multi node, Compact (three node), or Single node (SNO), or all | Applicable to all |
Connected / Restricted Network | Applicable to all |
Architectures, e.g. x86_x64, ARM (aarch64), IBM Power (ppc64le), and IBM Z (s390x) | Applicable to all |
Operator compatibility | Applicable to all |
Backport needed (list applicable versions) | Applicable to all supported versions |
UI need (e.g. OpenShift Console, dynamic plugin, OCM) | Yes |
Other (please specify) |
Outcome Overview
Once all Features and/or Initiatives in this Outcome are complete, what tangible, incremental, and (ideally) measurable movement will be made toward the company's Strategic Goal(s)?
Success Criteria
When all the features in the Outcome are complete. Users will be able to update control plane independent of worker nodes.
They can use any channels to go from N to N+3 version after the skew change.(currently only N to N+2 version update is available via EUS-to-EUS update)
Expected Results (what, how, when)
The update quality is improving with every release.
We expect customers to have more confidence to update using fast and stable channel. The N to N+3 version skew change will help them update to latest version. We think this will encourage customer to update to latest versions.
Post Completion Review – Actual Results
After completing the work (as determined by the "when" in Expected Results above), list the actual results observed / measured during Post Completion review(s).
- depends on
-
OCPSTRAT-1162 Rename “supported but not recommended” as known issues
- Closed
-
OCPSTRAT-1153 Rename Channels in OpenShift
- Closed
- links to