Epic Goal

• Placeholder for any prototyping/spike tickets that are needed in order to meet the platform operator phase 0 requirements
• Ensure the highest risks for phase 0 have been sufficiently prototyped and designed upfront
• Help shape the design proposed in an enhancement proposal
• Help shape the long term migration path from the v1 OLM to v2 OLM
• Help provide insight into GA requirements for POs

Why is this important?

Over the last couple of years, the OLM team has been busy designing a new v1 architecture that's centered around splitting up the existing control plane
into individual components, and moving towards a descoped tenancy model. The platform operators (PO) phase 0 epic is the first concrete use case that
can be met using OLM's new APIs, which allows the OLM team to slowly start introducing a new control plane into the OCP payload and help shape the long term migration path from the legacy to new OLM control plane over the 4.x OCP release lifecycle.

This past quarter, the OLM team has been working towards productizing the "RukPak" OLM v1 component, which is responsible for sourcing and applying content on Kubernetes clusters.

Due to OLM's v1 design still being solidified, and the rukpak component is still in the MVP phase, this new, separate control plane introduces a new set of open questions and complexity.
In order to de-risk the overall phase 0 deliverable and help shape an enhancement proposal, iterating on prototypes can help answer some of the open questions, or provide more insight
into which alternatives are worth exploring further. Because we're early in the implementation of these components, investing in prototypes should be a low cost investment.

Acceptance Criteria

• All upfront design has been completed and will help shape an overall phase 0 enhancement proposal
• Provide working prototypes that can solicit feedback from stakeholders
• The requirements for phase 0 have been gathered from stakeholders
• The scope for the phase 0 design has been accepted by stakeholders

Previous Work (Optional):

• The OLM's v1 e2e strawman
• RukPak

Open questions:

• What are the support guarantees with introducing v1alpha1 APIs to the OCP payload?
• What bundle format will be used for phase 0?
• Do phase 0 requirements need a rukpak registry+v1 bundle format provisioner?
• Can legacy OLM be packaged as a PO?
• Do phase 0 requirements need a first-class, cluster-scoped PO API?
• What are the implications with running both legacy and new OLM on the same cluster?
• Can deppy be introduced with a slimmed down scope during the 4.12 release?
• How to expose Kubernetes version constraints for POs?
• Is OLM's OperatorCondition API sufficient for determining PO upgradeability, or is a separate, first-class API needed?
• Do the existing replaces/skip/skipRange upgrade graph semantics make sense long term?
• Do the existing CatalogSource and gRPC registry APIs make sense long term?

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>