Platform Operators - Sourcing Hybrid Catalog Content

--- title: Platform Operators - Sourcing Hybrid Catalog Content authors: - "@tylerslaton" - "@dsover" reviewers: - TBD approvers: - TBD creation-date: 2022-05-18 last-updated: 2022-04-18 status: provisional tags: wip --- # [WIP] Catalogs with Hybrid Bundle Formats ## Open Questions - Does a downstream version of RukPak need to exist somewhere? - Is a PlatformOperator aware that it is a PlatformOperator? Does it need to be 1:1 in functionality to its OLM counterpart if a legacy Bundle? ## Summary As we move closer to previewable PlatformOperator deliverable, the question of how we handle `plain+v0` and `registry+v1` bundles in the same world needs to be addressed. Currently, the discussion around PlatformOperators has been evolving over internal threads/meetings detailing how we manage both formats is no exception. This intent of this document is to serve as a way of aggregating thoughts, discussing trade-offs, and ultimately coming to a consensus on the best path forward. ## Motivation [Rukpak](https://github.com/operator-framework/rukpak) has been making great progress in recent sprints towards becoming productizeable. During the development process, the team focused on building on the `plain` provisioner which is responsible for handling `Bundles` with nothing but regular (`plain+v0`) Kubernetes manifests in them. As the project matures, the question of how to handle the existing OLM content catalogs/bundles is coming up and ultimately is a large deal for PlatformOperators. Supporting the legacy OLM bundle format is extremely important for adoption of our product as it allows bundle authors to continue using their existing format without interuption. The legacy bundle format makes sense for legacy OLM, but not entirely for users (or new ones) that simply want to apply Kubernetes manifests in a structured way without the complexity burden that CSV's provide. As a result, there is likely a world where we have both `plain+v0` and `registry+v1` bundles being using for PlatformOperators. The goal of this document is to determine if this is the best path forward, how we should go about navigating that path and being sure ### Goals - Determining if the hybrid approch is what we want to move towards - Discuss the potential trade-offs of a hybrid catalog - Outline a path forward for handling the two bundle formats - Ironing out the best path forward for users - Support both formats in a way that is backwards compatible (`registry+v1`) while also pushing forward towards a single format (`plain+v0`) ### Non-Goals - Putting bundle authors in a position where they need to rewrite their content manually - Fragmenting the operatorhub ecosystem - Replacing the `registry+v1` format ## User Stories ### Scenario 1 ### Scenario 2 ### Scenario 3 ## Options ### Hybrid catalog content #### Pros - Can support legacy (`registry+v1`) and next generation (`plain+v0`) formats at the same time - Migration to only using `plain+v0` becomes clearer #### Cons - Increases the complexity of building a catalog (somewhat alleviated by FBC) - Catalog needs to become aware of what `plain+v0` bundles are. New endpoint? - OLM needs to become aware of `plain+v0` bundles and not action on them. - Need to think of how RukPak and OLM don't step on each other's toes - PlatformOperator and OLM need to be aware of each other for a good UX ### Only supporting plain+v0 bundles #### Summary #### Pros - Reduced Rukpak and PlatformOperators resolution complexity - Rukpak remains unaware of the existing `registry+v1` format #### Cons - OLM would need to know how to ignore plain bundle catalogs - Need to convert all incoming `registry+v1` PO content to `plain+v0` - `plain+v0` format is currently immature, not reasonable to ask authors to use as is #### Risks and Mitigations - **Risk**: Segmenting our bundle author user base **Mitigation**: Provide authors with tool for conversion - **Risk**: Not supporting the full feature set that OLM provides **Mitigation**: Reaching feature parity with OLM - RBAC generation - Signed certs for webhooks - Automatic upgrades, concept of a subscription - Etc. #### Constraints - Relies on the assumption that a conversion tool is created ### Only supporting registry+v1 converted to plain bundles #### Summary #### Pros - Bundle authors can continue using their existing bundles without intervention - Pipelines can use their existing checks and workflows to build catalogs and deliver content to clusters - Bundles and BIs are less opaque due to the new APIs - Cascade deletion (with CRDs) #### Cons - Ecosystem remains stuck on a complex, opaque bundle format that is strongly coupled to legacy OLM - Users may be hestitant to use if the conversion is not handled well #### Risks and Mitigations - **Risk**: Conversion is not 1-1 and results in abnormal functionality. **Mitigation**: ## Design Details ### Test Plan ### Graduation Criteria ### Version Skew Strategy