-
Epic
-
Resolution: Done
-
Undefined
-
None
-
OLM v1 supports legacy upgrade edges
-
Upstream
-
False
-
None
-
False
-
Not Selected
-
To Do
-
OCPSTRAT-1375 - [Tech Preview phase III] Next-gen OLM (OLM v1)
-
OCPSTRAT-1375[Tech Preview phase III] Next-gen OLM (OLM v1)
-
0% To Do, 0% In Progress, 100% Done
OCP/Telco Definition of Done
Epic Template descriptions and documentation.
<--- Cut-n-Paste the entire contents of this description into your new Epic --->
Epic Goal
- OLM v1's upgrade logic should support the existing semantics that are already baked into operator metadata – specifically upgrade logic should respect the replaces, skips and skiprange values
Why is this important?
- OLM v1's initial release will focus on existing operators in the released catalogs. It needs to respect the graph definitions that operator developers have already published so that it does not break compatibility and upgrade packages in unexpected ways
Scenarios
- When OLM selects an upgrade edge for a Cluster Extension, it should restrict that choice based on the graph metadata in the catalog.
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- Release Technical Enablement - Provide necessary release enablement details and documents.
- ...
Dependencies (internal and external)
- ...
Previous Work (Optional):
- Upstream change: https://github.com/operator-framework/operator-controller/pull/743
Open questions::
- …
Done Checklist
- CI - CI is running, tests are automated and merged.
- Release Enablement <link to Feature Enablement Presentation>
- DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
- DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
- DEV - Downstream build attached to advisory: <link to errata>
- QE - Test plans in Polarion: <link or reference to Polarion>
- QE - Automated tests merged: <link or reference to automated tests>
- DOC - Downstream documentation merged: <link to meaningful PR>