Introduce v1beta2 conditions alongside v1beta1 conditions

[abdullah599]

Summary

Introduce new v1beta2 conditions in status.v1beta2.conditions for all CAPH resources, set alongside existing v1beta1 conditions during reconciliation, and add selected v1beta2-only conditions where they improve lifecycle visibility. This keeps CAPH aligned with the updated Cluster API contract and Kubernetes API conventions for conditions.

The Problem

CAPH currently uses v1beta1 conditions (clusterv1.Condition in status.conditions) across all its resources. Cluster API is transitioning to v1beta2 conditions as part of the Improving Status in CAPI Resources proposal, and all providers must complete this transition before v1beta1 removal.

The v1beta2 conditions differ from v1beta1 in ways that affect CAPH:

• Type: v1beta2 uses metav1.Condition (from k8s.io/apimachinery) instead of the custom clusterv1.Condition.
• Reason field: Always required, not just when a condition is False.
• Polarity: No longer restricted to positive-only. Negative polarity is allowed where it makes sense for humans (e.g., Paused is True when paused).
• Contract: The CAPI infra contract now requires status.conditions[Ready] on InfrastructureCluster and InfrastructureMachine to surface issues during the entire lifecycle, not just initial provisioning.

If we do not start this migration, CAPH will become incompatible with future CAPI releases (tentative Aug 2026).

The Solution

Important

Some of the decisions documented below may be revised as we work through individual resources and encounter specifics not covered by the general pattern.
This is especially true for polarity. We did not find any condition that clearly needs a negative polarity change right now, but this should be evaluated per condition during implementation. If an existing condition expresses negative context through a positive form, the v1beta2 version should use the corresponding negative polarity instead.

We will follow the same phased approach that CAPV (cluster-api-provider-vsphere) used on their release-1.14 branch:

• Add a V1Beta2 field to each resource's status struct: A new status.v1beta2 field containing a Conditions []metav1.Condition slice. This sits alongside the existing status.conditions (v1beta1).
• Set v1beta2 conditions alongside v1beta1 conditions in every reconciler: Wherever v1beta1 conditions are set today, we will also set the corresponding v1beta2 condition using v1beta2conditions.Set(). The existing v1beta1 condition-setting code remains unchanged.
• Implement GetV1Beta2Conditions() / SetV1Beta2Conditions() methods: Each resource type will implement these methods so the CAPI condition utilities can work with the new condition slice.
• Define v1beta2 condition constants: Create condition type and reason constants following the <Resource><ConditionName>V1Beta2Condition naming convention (matching CAPV's pattern).
• Add selected v1beta2-only conditions: We will add Deleting(with Negative Polarity) for HetznerCluster, HCloudMachine, HetznerBareMetalMachine, and HetznerBareMetalHost, and leave HCloudRemediation and HetznerBareMetalRemediation as they are not primary infrastructure objects.

After this phase, both v1beta1 and v1beta2 conditions will coexist. Future phases will handle deprecation of v1beta1 conditions and migration of status.ready to status.initialization.provisioned.

Key Decisions

Decision	Choice	Rationale
Where to place new conditions	status.v1beta2.conditions	Follows CAPI proposal and CAPV pattern. Keeps v1beta1 untouched.
Polarity	Decide per condition during implementation	We did not identify any condition that clearly needs negative polarity yet. If implementation shows a condition carries negative meaning through a positive name, the v1beta2 condition should use the corresponding negative polarity.
New v1beta2-only conditions	In scope for this issue	We will add Deleting(with Negative Polarity) for HetznerCluster, HCloudMachine, HetznerBareMetalMachine, and HetznerBareMetalHost, and leave HCloudRemediation and HetznerBareMetalRemediation unchanged because they are not primary infrastructure objects.
Availability vs Readiness	Not needed(more discussion needed)	The Available vs Ready distinction applies to CAPI core resources. The infrastructure provider contract still requires Ready.
Deprecated v1beta1 conditions	Keep in status.conditions	Only new conditions go in status.v1beta2.conditions.

Sub-Issues (Will be created shortly)

Each sub-issue covers one resource type end-to-end (types, constants, reconciler, tests). All sub-issues can be worked in parallel since each touches different files.

Core contract resources:

1. HetznerCluster
2. HCloudMachine
3. HetznerBareMetalMachine
4. HetznerBareMetalHost

Remediation resources:
5. HCloudRemediation

References

• CAPI Proposal: Improving Status in CAPI Resources
• CAPI Contract: Changes for Infrastructure Providers
• CAPI Proposal: Readiness and Availability
• CAPV release-1.14 (reference implementation)