---
title: Platform Operators Roadmap
author: timflannagan
---

# Platform Operators Roadmap

## Roadmap

> Note: The items outlined in the following phases are subject to change.

### Phase 0

Status: Dev complete. Delivered through TP guidelines.

- Productize and integrate with OLM's 1.x "rukpak" component.
- Add initial support for installing platform operators.
- Add initial support for proxying platform operator status to the CVO.

### Phase 1

Status: Initial prototyping / pre-planning. Likely delivering through TP guidelines again.

- Productize OLM's 1.x "deppy" component.
- Integration with the CVO and influence cluster upgrade lifecycle events.
- Support upgrading platform operators are inital installation.
- Support sourcing platform operators from all catalogs in the cluster.
- Engage with early candidate platform operator teams.

Non-Functional Requirements:

- Drop the redhat-operators catalog source requirement.
- Keep the requirement around only supporting maxOpenShiftVersion/minKubeVersion constraint definitions.
- Likely keep the registry+v1 bundle format requirement given the plain bundle format doesn't have a way to express metadata, and the pipelines aren't able to support this bundle format yet.
- Likely keep the AllNamespace CSV install mode requirements. There's been initial conversations around supporting all common install modes but we haven't prioritized any spike work for evaluating whether this is technically possible.
- Likely keep the requirement around no specified webhook/APIService definitions.

Open Questions:

- Do we need any top-level API changes here? How far can we get with just allowing admins to configure the package name? From early conversations, it sounds like we want to move towards a version range field that admins can configure but that doesn't have to happen immediately.
- Do we need some sort of allowlist of "blessed" platform operator candidates during this phase, or is codifying any requirements sufficient?
- Do we need to accommodate any preflight checks, or can we batch upgrade everything at once?

### Phase 2

Status: TODO.

- Integrate with the installer
- Dependency on external team (installer)
- See <https://coreos.slack.com/archives/C030W4V9BHN/p1664299077224339> for an initial discussion on this topic.
- Integrate with OLM's 1.x deppy sub-project.
- Dependent on deppy productization progress.
- Add support for declaratively configuring probes in rukpak.
- Ensure's runtime failures are properly bubbled up to the platform operator status.
- See <https://hackmd.io/lUnrQHaKTsCLZ6j3Q52hSQ#> for prior ART.
- See <https://coreos.slack.com/archives/C030W4V9BHN/p1656703970521279> for initial conversations on this topic.
- See <https://coreos.slack.com/archives/C030W4V9BHN/p1652882555449369> for more context of this topic.

Requirements:

- N/A.

Open Questions:

- N/A.

### Phase 3

Status: TODO.

- QoL improvements?

### Backlog

Note: This isn't in prioritized order. Needs grooming.

- Respect SNO cluster topologies
- Integrate with hypershift.
- Integrate with KCP.
- Integrate with the console.
- A dedicated downstream rukpak controller.
- Support disconnected environments.
- Support multi-format catalogs.
- Add support for expressing metadata in the plain bundle format.
- Productize the plain bundle format.
- Pipelines support the plain bundle format.
- Introduce more fine-grained admin controls.
- Respect any upgrade graph mechanisms defined.
- Outline a migration plan for current CVO-based components that could be deployed through this platform operators mechanism
- Support a first-class way for platform operators to communicate their individual status.
- Enforcing cluster invariants for platform operators through deppy.
- Evaluate whether the CVO needs to be aware of ClusterOperators created outside of the payload.
- Evaluate how to identify platform operators from catalog contents.
- Evaluate whether platform operators dependency requirements are supported.