-
Feature
-
Resolution: Done
-
Critical
-
None
-
Strategic Product Work
-
False
-
-
False
-
-
0% To Do, 0% In Progress, 100% Done
-
0
-
Program Call
Feature Overview (aka. Goal Summary)
- OLM replaces the older version of the extensions with a newer version atomically either automatically or manually defined by the administrative personas.
Goals (aka. expected user outcomes)
- All versions along the update path should be allowed for selection by the user as the desired target version.
- OLM 1.0 will replace the current version of the Operator with the desired target version and users can check the progress of that transition, on the user-facing Operator API.
- OLM 1.0 now enables users to set operator updates to be applied automatically but are bound to patch releases only.
- OLM 1.0 enables an upgrade that ignores the upgrade edges to make it possible to force an update to a certain version, even if there is no direct path as per the graph metadata.
Requirements (aka. Acceptance Criteria):
| Requirement | Notes | isMvp? |
|---|---|---|
| As extensions get updated, either automatically (i.e., initiated by the OLM) or manually (i.e., initiated by the users), OLM replaces the older version of the extensions with a newer version atomically. | YES | |
| All versions along the update path should be allowed for selection by the user as the desired target version. | YES | |
| Users can set operator updates to be applied automatically but bound to patch releases only. | YES | |
| It should also be possible to force an update to a certain version, even if there is no direct path as per the graph metadata. | YES | |
| An update should be able to be rolled back by an admin (with F23) up until any custom code or conversion logic runs. | YES | |
| When multiple extensions are updated to satisfy an update request, the update policy of each extension needs to be respected to allow users to pin certain extensions to installed versions or certain types of updates (e.g. z-stream only). | The new design needs to solve the current `InstallPlan` API's issue: each Operator can have its own distinct update policy that needs to be honored. |
NO |
| CI - MUST be running successfully with test automation | This is a requirement for ALL features. | YES |
| Release Technical Enablement | Provide necessary release enablement details and documents. | YES |
Use Cases
- OLM 1.0 users can specify a specific version along the update path as the desired target version for the extension update.
- OLM 1.0 users can check the progress of that transition, on the user-facing Operator API.
- OLM 1.0 users can force an extension update to a specific version, even if there is no direct path as per the graph metadata.
- OLM 1.0 users can set operator updates to be applied automatically but are bound to patch releases only.
Definition of Done / Acceptance criteria
- All use cases above are implemented and meet the requirements (requirements for MVP takes priority).
- Although not part of this feature, the design should take how F23 (Opt-in to fallback/rollback) can be implemented into consideration.
Background, and strategic fit
This is part of a larger effort to re-design vital parts of the OLM APIs and conceptual models to fit the use case of OLM in managed service environments, GitOps-controlled infrastructure and restrictive self-managed deployments in Enterprise environments. You can learn more about it here: https://docs.google.com/document/d/1LX4dJMbSmuIMn98tCiBaONmTunWR6zdUJuH-8uZ8Cno/edit?usp=sharing
Relevant upstream CNCF OLM engineering brief(s):
- Brief: Support version ranges
- Brief: Initial upgrade support
- Brief: Report BundleDeployment Health
Documentation Considerations
- (“Operators > Administrator tasks” section) OLM 1.0 users know how to specify a specific version along the update path as the desired target and know how to check the progress of that transition, on the user-facing Operator API.
- (“Operators > Administrator tasks” section) “OLM 1.0 users know how to force an extension update to a specific version, even if there is no direct path as per the graph metadata.
- split from
-
-
- New
-
- split to
-
-
- Closed
-
