Epic Goal

  Migrate CAPI provider manifest delivery from CVO transport ConfigMaps to image-embedded manifests. Each provider's container image carries its own manifests and metadata under /capi-operator-manifests/. The CAPI installer extracts, filters, and applies
  these at runtime.

  Why is this important?

  Provider manifests are currently delivered as ConfigMaps via CVO. This decouples provider code from its manifests: they live in separate repos and merge independently, which causes payload breakage when a provider image isn't backward-compatible with the
   previous version's manifests. Baking manifests into provider images means:
  - We can identify exactly which manifest versions are deployed at any given time
  - Provider code and manifests are atomically versioned together, eliminating cross-repo merge ordering issues
  - Manifests too large for ConfigMap's 1MiB limit are handled naturally
  - Provider-specific manifest customization moves into provider repos where it belongs
  - Lays groundwork for revision controller, feature-gated profiles, and a reimplemented installer using Boxcutter

  Scenarios

  1. New cluster bootstrap (image-only providers): CAPI installer pulls provider images at startup, extracts manifests from /capi-operator-manifests/, filters by platform, applies in install-order.
  2. Mixed deployment (transition period): Some providers still use ConfigMaps, others use image-embedded manifests. Installer runs both paths: ConfigMap-based first, then image-based. Not expected to ship in any release.
  3. Provider rebase: RebaseBot rebases a provider fork, invokes manifests-gen via kustomize, generates metadata.yaml + manifests.yaml under openshift/capi-operator-manifests/default/. Output is baked into the provider image via Dockerfile. Single PR,
  single repo.
  4. Platform-specific filtering: Infrastructure providers specify ocpPlatform in metadata. Installer skips providers that don't match the running cluster's platform.
  5. Multi-profile (future): A single provider image contains multiple profiles (e.g. default, featuregate-foo). Installer processes all matching profiles. Profile selection by FeatureGate is out of scope for this epic but the format supports it.

  Acceptance Criteria

  - manifests-gen produces metadata.yaml (new ProviderMetadata format with Name, Attributes, OCPPlatform, SelfImageRef, InstallOrder) and manifests.yaml per profile
  - manifests-gen applies OpenShift customizations (cert-manager to service-ca, namespace overrides, provider labels, selfImageRef substitution, ValidatingAdmissionPolicy for protected cluster resources)
  - CAPI installer controller supports both ConfigMap-based and image-based manifest delivery concurrently (interim state)
  - CAPI installer pulls provider images using cluster pull secret, extracts /capi-operator-manifests/, caches to disk
  - CAPI installer filters profiles by platform, sorts by InstallOrder, applies via shared applyProviderComponents path
  - All providers migrated to image-embedded manifests:
    - cluster-api (core, install-order 10)
    - cluster-api-provider-aws (AWS, install-order 20)
    - cluster-api-provider-azure (Azure)
    - cluster-api-provider-gcp (GCP)
    - cluster-api-provider-vsphere (VSphere)
    - cluster-api-provider-ibmcloud (IBMCloud/PowerVS)
    - cluster-api-provider-openstack (OpenStack)
    - cluster-api-provider-metal3 (BareMetal)
    - cluster-api-provider-kubevirt (KubeVirt)
    - cluster-api-provider-nutanix (Nutanix)
  - Each migrated provider has a make verify target that regenerates manifests and diffs against checked-in content
  - Old CVO ConfigMap manifests removed from migrated providers
  - CI running successfully with tests automated

  Release Technical Enablement

  - Enhancement: https://github.com/openshift/enhancements/pull/1918
  - No user-facing API changes; internal operator plumbing (TechPreview only)
  - No behavioral change from user perspective. CAPI providers are installed the same way, just delivered differently.

  Dependencies (internal and external)

  - openshift/cluster-capi-operator: manifests-gen tool, providerimages package, installer controller changes
  - openshift/enhancements#1918: enhancement approval
  - Each provider fork (openshift/cluster-api-provider-{aws,azure,gcp,vsphere,ibmcloud,openstack,metal3,kubevirt,nutanix}): per-provider migration PRs
  - openshift/cluster-api: core provider migration (already done)
  - RebaseBot lifecycle hooks: must support invoking manifests-gen during rebase

  Previous Work

  Open Questions

  - When does the interim ConfigMap+image dual path get removed in favor of image-only? Blocked on all providers migrating.

  Done Checklist

  - CI: CI is running, tests are automated and merged.
  - Release Enablement
  - DEV: Upstream code and tests merged:
  - DEV: Upstream documentation merged:
  - DEV: Downstream build attached to advisory:
  - QE: Test plans in Polarion:
  - QE: Automated tests merged:
  - DOC: Downstream documentation merged: