-
Epic
-
Resolution: Done
-
Major
-
None
-
None
-
None
-
Catalogd Functional Improvements
-
Upstream
-
False
-
None
-
False
-
Not Selected
-
Done
-
OCPSTRAT-429 - [Phase 2 MVP/Tech Preview] OLM 1.0 - Extension Catalogs (F1)
-
-
0% To Do, 0% In Progress, 100% Done
Epic Goal
- To separate the serving of catalog data from the mechanisms that reconciles and stores that data. This essentially keeps query/response load off of the kubernetes apiserver and moves it to a separate HTTP server.
Why is this important?
Relevant Links
Upstream epic issue: https://github.com/operator-framework/catalogd/issues/139
Scenarios
- ...
Acceptance Criteria
- CI - MUST be running successfully with tests automated
- Release Technical Enablement - Provide necessary release enablement details and documents.
- Operator Controller can successfully install an Operator, using catalogd’s HTTP server to fetch catalog contents for resolution.
- A user can fetch the contents for a particular Catalog resource by issuing a GET request to the content URL in the Catalog.Status.
- Package, BundleMetadata, and CatalogMetadata APIs are not installed when installing catalogd and the corresponding feature gates and functionality are removed.
Dependencies (internal and external)
- ...
Previous Work (Optional):
- …
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>