-
Epic
-
Resolution: Done
-
Major
-
openshift-4.14
-
None
-
FBC: 1TO5
-
Strategic Product Work
-
False
-
None
-
False
-
Not Selected
-
Done
-
OCPSTRAT-586 - [Pilot phase] Enable managing releases with the file-based catalog for Red Hat Operator teams with RHTAP
-
OCPSTRAT-586[Pilot phase] Enable managing releases with the file-based catalog for Red Hat Operator teams with RHTAP
-
0% To Do, 0% In Progress, 100% Done
OCP/Telco Definition of Done
Epic Template descriptions and documentation.{}
Epic Goal
- OCP community operator authors need a clean approach to support multiple OCP releases with minimal veneer/FBC. As part of https://docs.google.com/document/d/1DZaDkZz8l-L911tZ26_5lmm8uYJ8g9etBWRXbUeSLdM/edit#heading=h.h9wqoxeg6yjv Model A we must support the current ecosystem, which includes a common location for operator bundles. We must overlay FBC-generation capabilities as part of the existing repository organization to provide authors with control over their catalog contributions without necessitating re-homing their bundles, catalog contributions to discrete repositories.
- This epic captures the pieces of this work necessary for the pilot phase.
Why is this important?
- Operator authors have expressed reluctance to migrate to FBC given that they
- now have to separately manage their upgrade graph catalog contribution; and
- may have to separately manage per-supported-OCP-version veneer/FBC information; and
- may not be able to leverage veneers while retaining control of which bundles are included for each release
Scenarios
- author needs to use different veneer types for different OCP releases
- author needs to generate FBC for multiple releases from the same template
- author needs to omit some bundle versions from some subset of supported OCP releases
- author needs to automate a toolchain containing these steps (i.e. cannot force interactive mode)
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- output must be idempotent given same inputs
Dependencies (internal and external)
- multiple-release support: work with lgallett and team to collaborate on https://docs.google.com/document/d/1uEZdVA06GGahPl3ygnGrFLRkrohaQjs25mVcXToYakE
Previous Work (Optional):
- Rejected proposal for `veneergroup` veneer https://hackmd.io/dD3h4K3tRi-fF3Z3SAuGKA
- Demonstrated veneergroup-via-Makefile approach: https://github.com/ankitathomas/veneergroup
- "Covington" veneer proposal, containing bundle optionality: https://hackmd.io/q8uAu2PjRZSlueutc5McBw#Covington
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>
- is cloned by
-
OPECO-2851 Community operator authors have a clean approach to supporting FBC for multiple OCP releases
- Closed
- relates to
-
OPECO-2773 Catalog maintainers have a way to ensure the same opm version is used for all catalog operations
- New