/kind cleanup
What needs cleanup:
https://cluster-api.sigs.k8s.io/developer/providers/migrations/v1.10-to-v1.11.html#how-to-implement-the-new-v1beta2-contract
v1beta1 API version is deprecated and it will be removed tentatively in August 2026
Implementation plan:
v1beta2 Contract Migration Roadmap
Create a new api/v1beta2 CAPZ provider API version with full v1beta2 CAPI contract compliance, conversion webhooks for backward compatibility, and migrate all controllers.
Why a new API version?
We initially tried adding v1beta2 contract fields to the existing api/v1beta1 types (PRs #6199, #6202). This works for initialization.provisioned and v1beta2.conditions, but fails when declaring v1beta2 contract compliance because failureDomains changed from a map to a slice in the v1beta2 contract. CAPI's backward compatibility only handles the map format when the contract label says v1beta1, so there is no way to declare v1beta2 compliance without converting failureDomains — a breaking schema change that requires a new API version. This is also consistent with how CAPZ handled previous contract transitions (v1alpha3/v1alpha4 → v1beta1).
Plan
PR 1 (Types + Conversion + CRD config) ──> PR 2 (Controllers + Tests)
Future work
- Add granular v1beta2 conditions (
NetworkInfrastructureReady, SubnetsReady, etc.) — CAPZ-internal, not part of the CAPI contract
- Remove
api/v1beta1 and status.deprecated.v1beta1 (after transition period)
- CRD Migrator adoption (orthogonal)
References
/kind cleanup
What needs cleanup:
https://cluster-api.sigs.k8s.io/developer/providers/migrations/v1.10-to-v1.11.html#how-to-implement-the-new-v1beta2-contract
v1beta1 API version is deprecated and it will be removed tentatively in August 2026
Implementation plan:
v1beta2 Contract Migration Roadmap
Create a new
api/v1beta2CAPZ provider API version with full v1beta2 CAPI contract compliance, conversion webhooks for backward compatibility, and migrate all controllers.Why a new API version?
We initially tried adding v1beta2 contract fields to the existing
api/v1beta1types (PRs #6199, #6202). This works forinitialization.provisionedandv1beta2.conditions, but fails when declaring v1beta2 contract compliance becausefailureDomainschanged from a map to a slice in the v1beta2 contract. CAPI's backward compatibility only handles the map format when the contract label says v1beta1, so there is no way to declare v1beta2 compliance without convertingfailureDomains— a breaking schema change that requires a new API version. This is also consistent with how CAPZ handled previous contract transitions (v1alpha3/v1alpha4 → v1beta1).Plan
PR 1: Create
api/v1beta2types, conversion webhooks, CRD config (~80+ files)api/v1beta2/andexp/api/v1beta2/with all type definitions, applying v1beta2 contract changes:status.ready→status.initialization.provisioned *boolstatus.initialized→status.initialization.controlPlaneInitialized *boolstatus.conditionsuses[]metav1.Condition, old conditions moved tostatus.deprecated.v1beta1.conditionsstatus.failureDomainschanged from map to slicefailureReason/failureMessagemoved tostatus.deprecated.v1beta1spec.providerIDchanged from*stringtostringcluster.x-k8s.io/v1beta2: v1beta2) andcontract: v1beta2tometadata.yamlPR 2: Migrate controllers to v1beta2 types (~60+ files)
api/v1beta2typesutil/conditions+util/patchpackages (not the deprecatedutil/deprecated/v1beta1/*packages)initialization.provisionedinstead ofreadymetav1.Conditionconditions, with backward compat old conditions indeprecated.v1beta1Availablecondition for AzureManagedControlPlane (ControlPlane contract)Future work
NetworkInfrastructureReady,SubnetsReady, etc.) — CAPZ-internal, not part of the CAPI contractapi/v1beta1andstatus.deprecated.v1beta1(after transition period)References