Feature Overview

See OCPSTRAT-2618

Goals

See OCPSTRAT-2618

Requirements - Phase 3:

Planning and performing platform upgrades now incorporates planning, review and conducting operator updates in two forms:

Regular extensions:

• operators like GitOps, Pipelines, Service Mesh etc. are listed displaying compatibility  with the next platform version
• update options are recommended based on compatibility and recommended version compatible with the target platform version

Platform operators:

• platform-aligned operators like ODF, CNF, ACM, Quay et al are listed along with the version they would upgrade to as part of the platform update, no version selection is possible

All information should be accessible via APIs for use in Cluster Console, CLIs, and ACM.

All information related to newly available operator versions discussed in OCPSTRAT-2618 is also available in this context.

A combined platform and operator upgrade can be triggered, and based on operator metadata, the operators are updated before or after the platform upgrade.

Use Cases:

• A platform engineer plans a new major/minor platform upgrade and reviews operator compatibility. They can discover which operator must be updated in order to achieve compatibility with the new version and which operator can be updated to run the recommended version for the given platform version.
• A platform engineer can update the platform and rest assured that platform-aligned operators are updated to the correct version in the correct sequence

Out of Scope

For now: Helm

Background

Read the full proposal here: https://docs.google.com/document/d/1MzGGov5slwnEmohoW4ZSVvhxSiaBXRlWjSzoO3affMY/edit?tab=t.mepx4xanj5dv 

Interoperability Considerations

This experience must be available without degradation in disconnected environments lacking direct internet access and AI capabilities.