Epic Goal

This feature introduces Cluster API (CAPI) as the underlying technology for managing the lifecycle of OpenShift Container Platform (OCP) clusters on VMware vSphere. The primary goal is to migrate from the current Machine API (MAPI) implementation to a native CAPI-based approach. This strategic change aligns OCP's infrastructure management with upstream, Kubernetes-native standards, creating a unified and more maintainable solution for both initial cluster provisioning (day-0) and subsequent management operations (day-2).

Goals

The main goal is to achieve feature parity with the existing vSphere related machine API resource and capabilities while replacing the underlying provisioning engine with Cluster API.

• Primary Persona: Cluster Administrator
• Expanded Functionality:
  • Replace the machine API provisioning mechanism with the official CAPI Provider for vSphere (CAPV).
  • Provide a seamless, Kubernetes-native API foundation for managing cluster infrastructure.
  • Improve and standardize the implementation of related features, such as Control Plane Machine Set, Static IP support, and Multi-NIC, by leveraging a common CAPI interface.

Requirements

Functional Requirements:

• The installer must be able to deploy a new OCP cluster on supported versions of VMware vSphere and VMware Cloud Foundation (VCF) using CAPI.
• The feature must provide a clear and reliable upgrade path for existing OCP clusters from a MAPI-based version to a new CAPI-managed version.
• The CAPI-based implementation must maintain functional parity with the existing MAPI solution.

Non-Functional Requirements:

• Performance: The time required to provision, scale, and upgrade clusters should be comparable to or better than the existing implementation.
• Reliability: The installation and upgrade success rates must remain at or above current levels.
• Maintainability: The new implementation must reduce engineering overhead by removing the dependency on Terraform and aligning with upstream CAPI development.
• Usability: The user experience for the Cluster Administrator should remain consistent and straightforward, without introducing new complexities for standard installation or upgrade procedures.

Use Case

• User Story 1 (New Installation): As a Cluster Administrator, I want to deploy a new OCP cluster on the vSphere/VCF platform, so that a new OCP cluster is provisioned using CAPI.
• User Story 2 (Upgrade): As a Cluster Administrator, I want to upgrade my existing OCP clusters on vSphere/VCF to the new OCP version which supports CAPI.

Questions to Answer

The following questions need to be addressed during the design and architecture phase:

1. What specific, observable changes will a Cluster Administrator experience during or after the installation (e.g., changes to install-config.yaml, new CRDs for day-2 management)?
2. How, specifically, will migrating to CAPI impact the implementation and user experience of Control Plane Machine Set, Static IP support, and Multi-NIC on vSphere?
3. What is the strategy for handling features where the upstream CAPI Provider for vSphere (CAPV) may have functional gaps compared to our existing Terraform implementation?
4. What specific version of the CAPI Provider for vSphere (CAPV) will be the target for this implementation?

Out of Scope

To be determined during the planning phase.

Links

• Upstream Project:[ Cluster API Quick Start|https://cluster-api.sigs.k8s.io/user/quick-start.html]
• OCP Documentation:[ Installing on VMware vSphere|https://www.google.com/search?q=[https://docs.redhat.com/en/documentation/openshift_container_platform/4.19/html-single/installing_on_vmware_vsphere/index]]

  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>