Feature Overview

• As a Cluster Administrator, I want to opt-out of certain operators at deployment time using any of the supported installation methods (UPI, IPI, Assisted Installer, Agent-based Installer) from UI (e.g. OCP Console, OCM, Assisted Installer), CLI (e.g. oc, rosa), and API.

• As a Cluster Administrator, I want to opt-in to previously-disabled operators (at deployment time) from UI (e.g. OCP Console, OCM, Assisted Installer), CLI (e.g. oc, rosa), and API.
• As a ROSA service administrator, I want to exclude/disable Cluster Monitoring when I deploy OpenShift with HyperShift — using any of the supported installation methods including the ROSA wizard in OCM and rosa cli — since I get cluster metrics from the control plane.  This configuration should be persisted through not only through initial deployment but also through cluster lifecycle operations like upgrades.
• As a ROSA service administrator, I want to exclude/disable Ingress Operator when I deploy OpenShift with HyperShift — using any of the supported installation methods including the ROSA wizard in OCM and rosa cli — as I want to use my preferred load balancer (i.e. AWS load balancer).  This configuration should be persisted through not only through initial deployment but also through cluster lifecycle operations like upgrades.

Goals

• Make it possible for customers and Red Hat teams producing OCP distributions/topologies/experiences to enable/disable some CVO components while still keeping their cluster supported.

Scenarios

1. This feature must consider the different deployment footprints including self-managed and managed OpenShift, connected vs. disconnected (restricted and air-gapped), supported topologies (standard HA, compact cluster, SNO), etc.
2. Enabled/disabled configuration must persist throughout cluster lifecycle including upgrades.
3. If there's any risk/impact of data loss or service unavailability (for Day 2 operations), the System must provide guidance on what the risks are and let user decide if risk worth undertaking.

Requirements

• This Section:* A list of specific needs or objectives that a Feature must deliver to satisfy the Feature.. Some requirements will be flagged as MVP. If an MVP gets shifted, the feature shifts. If a non MVP requirement slips, it does not shift the feature.

(Optional) Use Cases

This Section:

• Main success scenarios - high-level user stories
• Alternate flow/scenarios - high-level user stories
• ...

Questions to answer…

• ...

Out of Scope

• …

Background, and strategic fit

This part of the overall multiple release Composable OpenShift (OCPPLAN-9638 effort), which is being delivered in multiple phases:

Phase 1 (OpenShift 4.11): OCPPLAN-7589 Provide a way with CVO to allow disabling and enabling of operators

• CORS-1873 Installer to allow users to select OpenShift components to be included/excluded
• OTA-555 Provide a way with CVO to allow disabling and enabling of operators
• OLM-2415 Make the marketplace operator optional
• SO-11 Make samples operator optional
• METAL-162 Make cluster baremetal operator optional
• OCPPLAN-8286 CI Job for disabled optional capabilities

Phase 2 (OpenShift 4.12): OCPPLAN-7589 Provide a way with CVO to allow disabling and enabling of operators

• CONSOLE-3160 Make console operator optional
• CCXDEV-8079 Make Insights operator optional
• CNF-5645 Make storage operator optional
• CNF-5646 Make csi-snapshot-controller optional 

Phase 3 (OpenShift 4.13): OCPBU-117

• OTA-554 Make oc aware of cluster capabilities
• PSAP-741 Make Node Tuning Operator (including PAO controllers) optional

Phase 4 (OpenShift 4.14): OCPSTRAT-36 (formerly OCPBU-236)

• CCO-186 ccoctl support for credentialing optional capabilities
• MCO-499 MCD should manage certificates via a separate, non-MC path (formerly IR-230 Make node-ca managed by CVO)
• CNF-5642 Make cluster autoscaler optional
• CNF-5643 - Make machine-api operator optional
• WRKLDS-695 - Make DeploymentConfig API + controller optional
• CNV-16274 OpenShift Virtualization on the Red Hat Application Cloud (not applicable)
• CNF-9115 - Leverage Composable OpenShift feature to make control-plane-machine-set optional
• BUILD-565 - Make Build v1 API + controller optional
• CNF-5647 Leverage Composable OpenShift feature to make image-registry optional (replaces IR-351 - Make Image Registry Operator optional)

Phase 5 (OpenShift 4.15): OCPSTRAT-421 (formerly OCPBU-519)

• OCPVE-634 - Leverage Composable OpenShift feature to make olm optional
• CCO-419 (OCPVE-629) - Leverage Composable OpenShift feature to make cloud-credential optional

Phase 6 (OpenShift 4.16): OCPSTRAT-731

• OCPSTRAT-346 (OCPBU-352) Make Ingress Operator optional
• OCPCLOUD-2151 (OCPVE-628) - Leverage Composable OpenShift feature to make cloud-controller-manager optional

Phase 7 (OpenShift 4.17): OCPSTRAT-1308

• MON-3152 (OBSDA-242) Optional built-in monitoring
• IR-400 - Remove node-ca from CIRO*
• CNF-9116 Leverage Composable OpenShift feature to machine-auto-approver optional
• CCO-493 Make Cloud Credential Operator optional for remaining providers and topologies (non-SNO topologies)

References

• Composable OpenShift Roadmap Initial Proposal
• Composable Install

Assumptions

• ...

Customer Considerations

• ...

Documentation Considerations

Questions to be addressed:

• What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)?
• Does this feature have doc impact?
• New Content, Updates to existing content, Release Note, or No Doc Impact
• If unsure and no Technical Writer is available, please contact Content Strategy.
• What concepts do customers need to understand to be successful in [action]?
• How do we expect customers will use the feature? For what purpose(s)?
• What reference material might a customer want/need to complete [action]?
• Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available.
• What is the doc impact (New Content, Updates to existing content, or Release Note)?