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

• Enable OLM operators to participate in the lifecycle of a cluster installation

Why is this important?

The motivation for platform operators is two-fold. The strategic direction for OpenShift is to make the core installation smaller by default and at the same time make it more flexible so that customers can tailor their installations to their use cases. This is what we’re calling “Composable OpenShift”.

To make the core smaller, OpenShift is attempting to reduce the CVO-managed payload to the very minimum set of operators required to run the OpenShift control plane. From a control plane perspective, any non-essential operators can be installed after the cluster has been installed (or upgraded). However, from a customer standpoint, their business needs may dictate that these non-essential operators are still included in the lifecycle of cluster installations and upgrades. The Platform Operator (PO) concept will allow cluster administrators to choose which of these non-control-plane-essential operators to include in the cluster lifecycle.

Secondly, some portion of the layered product operators in the OpenShift catalogs are conducive with inclusion in the cluster lifecycle (e.g. cert-manager, service binding operator, and the local storage operator). The Platform Operator concept will open the door for more of OLM’s optional operators to be included in (and impact) the cluster lifecycle. This will allow customers to further tailor their cluster installs and upgrades to their business needs.

Scenarios

1. Prior to cluster installation, a cluster admin can designate a set of OLM operators that have been deemed to support installation as a Platform Operator to be installed and lifecycled with the cluster installation itself.
2. The CVO considers platform operators in its calculation of the progression of the cluster installation.
3. A platform operator cannot declare dependencies on other operators.
4. A platform operator can declare a dependency on a range of kubernetes minor versions, encoded as a range.
5. A platform operator can declare a dependency on a range of OCP minor versions, encoded as a range.
6. A platform operator whose kubernetes and/or OCP dependency ranges would be violated by a cluster upgrade must result in that cluster upgrade being blocked.
7. By default platform operators require manual cluster admin approval to upgrade to the next available version of the platform operator except during cluster minor version upgrades, during which platform operators are upgraded automatically.
8. Cluster administrators may opt for automatic upgrades of platform operators, in which case platform operators will be upgraded whenever there is an available upgrade edge to another version that tolerates the current cluster version.

Requirements to be a Phase 0 Platform Operator

1. The operator must ship with support for all architectures that OCP supports
2. The operator must support disconnected mode
3. The operator must not require any manual pre-install steps
4. The operator must ship PO bundles in a channel called "platform"
5. The operator must not allow multiple installations of itself in a cluster (e.g. if using registry+v1 bundles, it must support AllNamespaces only; if using plain+v0, it is implicitly de-scoped).
6. In order to support cluster rollback within an OpenShift Z-stream, the operator must not introduce CRD schema or version changes without also bumping the cluster version dependency (i.e. CRD schema and version changes are only allowed when crossing minor version boundaries)?

Acceptance Criteria

• CI - MUST be running successfully with tests automated
• Release Technical Enablement - Provide necessary release enablement details and documents.
• ... (TBD) ...

Dependencies (internal and external)

1. CVO - must understand how to include PO-labeled operators in cluster install lifecycle
2. Installer - must enable cluster admins to select set of POs when configuring a cluster installation.
3. Operator pipeline - must create a new pipeline to build a PO catalog.

Previous Work:

1. Rukpak (alpha provisioner and plain bundles)
2. OLM support for minKubeVersion in existing APIs
3. OLM support for maxOpenShiftVersion in existing APIs

Future Work (out of scope for now):

1. POs are upgraded when the cluster upgrades
2. POs can depend on other POs
3. PO upgrades can be held until a cluster upgrade is initiated
4. First class PO API exists
5. First class PO UI exists
6. More expressive dependency specification/resolution (requires cluster input into resolution so that operators can depend on attributes of non-operators)

Open questions:

1. N/A.

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>