Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-2320

MAPI to CAPI migration - Assisted Installer/ZTP/Infra Operator

XMLWordPrintable

    • Product / Portfolio Work
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      [Draft]

      Feature Overview

      This feature initiates the migration from the proprietary Machine API (MAPI) to the community-standard Cluster API (CAPI) for cluster lifecycle management within Assisted Installer, Infra Operator, and related Zero Touch Provisioning (ZTP) workflows. By adopting CAPI, OpenShift Container Platform (OCP) will align with the broader Kubernetes ecosystem, providing a more consistent, declarative, and extensible API for managing cluster infrastructure. The initial focus is on achieving feature parity with the existing MAPI implementation.

      Goals

      The primary goal is to replace MAPI with CAPI for all cluster and machine management operations driven by the Assisted Installer and ZTP, ensuring a seamless transition with no loss of functionality.

      As a Cluster Administrator, I want to:

      • Use the Assisted Installer with a CAPI provider to provision an OCP cluster, so that I can leverage the standardized lifecycle management capabilities of CAPI.
      • Add Day-2 nodes to a HyperShift-hosted cluster using CAPI-based mechanisms, so that I can scale my clusters declaratively.

      This feature expands upon the existing installation and Day-2 management capabilities of Assisted Installer, ZTP, and HyperShift by replacing the underlying machine management API.

      Requirements

      Functional Requirements:

      • The system must support installing a new OCP cluster using the Assisted Installer with a CAPI infrastructure provider.
      • The system must support adding Day-2 worker nodes to an existing cluster (including HyperShift-hosted clusters) using CAPI.
      • The implementation must achieve feature parity with the current MAPI-based workflows.
      • All existing validation checks and pre-flight logic in the Assisted Installer must be compatible with the CAPI-based workflow.
      • The ZTP flow for bare metal deployments must be adapted to use CAPI for machine provisioning.

      Non-Functional Requirements:

      • Reliability: The CAPI-based installation process must be as reliable and robust as the existing MAPI-based process.
      • Maintainability: The new implementation should be modular and well-documented to simplify future maintenance and enhancements.
      • Usability: The user experience for administrators should remain consistent, with the underlying API change being largely transparent during the installation process.
      • Documentation: All relevant public documentation for Assisted Installer, ABI, and ZTP must be updated to reflect the move to CAPI. Internal engineering documentation should detail the architectural changes.

      Use Cases

      Scenario: Deploying a new OCP cluster using the Assisted Installer.

      • User Persona: Cluster Administrator
      • User Story: "As a Cluster Administrator, I want to deploy a new OCP cluster using the Agent-based Installer, so that I can leverage a declarative, standardized API (CAPI) for infrastructure management from Day 1."

      Scenario: Provisioning multiple clusters at the edge using Zero Touch Provisioning (ZTP).

      • User Persona: Cluster Administrator
      • User Story: "As a Cluster Administrator, I want to use ZTP to automatically deploy and manage the lifecycle of hundreds of edge clusters, so that I can scale my operations efficiently using CAPI-native constructs."

      Questions to Answer

      • What are the specific integration points in the Assisted Installer, assisted-service, and infra-operator that need to be modified to replace MAPI calls with CAPI calls?
      • How will we manage the coexistence of MAPI and CAPI during the transition period, if necessary?
      • How does this migration impact the Agent-based Installer workflow for disconnected environments?
      • What is the testing strategy to ensure feature parity and prevent regressions in both connected and disconnected ZTP scenarios?
      • How will Day-2 operations like machine replacement or cluster upgrades be handled under the CAPI model compared to MAPI?

      Out of Scope

      • This section is intentionally left empty.

      Links

      • Upstream CAPI Documentation:[ Cluster API User Quick Start|https://cluster-api.sigs.k8s.io/user/quick-start]
      • Internal CAPI Overview:[ What is Cluster API?|https://docs.google.com/document/d/153lz0L8NjtHHu8RNLOpoAyKOeSw1uLmggQzibRL2tTo/edit]

      CAPI Roadmap:[ Cluster API Roadmap 2025-06|https://docs.google.com/presentation/d/1W60ai6MWG8tuuP0QT5r7FihzvFPNjGLN8jaKojSD084/edit#slide=id.g2eb84fe545d_0_6]

              Unassigned Unassigned
              mzasepa Michal Zasepa
              None
              None
              None
              None
              None
              None
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated: