Summary
Add v1beta2 conditions to HCloudRemediation on v1.1.x while keeping the existing v1beta1 conditions unchanged.
The Problem
HCloudRemediation is the object that drives machine health check remediation for HCloud machines. When a MachineHealthCheck marks a machine as unhealthy, the remediation controller attempts to reboot the server and, if retries are exhausted, signals CAPI to delete the machine.
Today the remediation lifecycle is surfaced through v1beta1 conditions such as:
| Condition |
Purpose |
HCloudTokenAvailable |
Hetzner API credentials are valid and reachable |
HetznerAPIReachable |
The controller is not blocked by HCloud rate limiting |
These conditions are still needed and must keep their current behavior. At the same time, the CAPI v1beta2 transition requires HCloudRemediation to expose v1beta2 conditions in parallel so that tooling and other controllers can consume the new condition format.
The Solution
Follow the same structure used for HCloudMachine (PR #1935):
- Add
status.v1beta2.conditions to HCloudRemediation.
- Keep writing the existing v1beta1 conditions exactly as today.
- Add direct
v1beta2conditions.Set(...) calls in the same controller code paths that already set the v1beta1 conditions.
- Extend
HCloudRemediationScope.Close() to compute:
- the legacy v1beta1 summary
- the v1beta2
Ready summary
- the owned v1beta2 condition set for patching
This keeps the behavior explicit at each reconcile decision point and avoids a second translation layer that can drift from the real lifecycle logic.
Final Conditions
The final v1beta2 conditions added for HCloudRemediation are:
| Constant |
Type |
Polarity |
Notes |
HCloudRemediationReadyV1Beta2Condition |
clusterv1.ReadyV1Beta2Condition |
Positive |
Summary condition |
HCloudTokenAvailableV1Beta2Condition |
HCloudTokenAvailable |
Positive |
Shared common condition: true when HCloud credentials are valid and reachable |
HCloudRateLimitExceededV1Beta2Condition |
HCloudRateLimitExceeded |
Negative |
Shared common condition: set while the controller is rate limited by the HCloud API |
Summary
Add v1beta2 conditions to
HCloudRemediationonv1.1.xwhile keeping the existing v1beta1 conditions unchanged.v1.1.xThe Problem
HCloudRemediationis the object that drives machine health check remediation for HCloud machines. When aMachineHealthCheckmarks a machine as unhealthy, the remediation controller attempts to reboot the server and, if retries are exhausted, signals CAPI to delete the machine.Today the remediation lifecycle is surfaced through v1beta1 conditions such as:
HCloudTokenAvailableHetznerAPIReachableThese conditions are still needed and must keep their current behavior. At the same time, the CAPI v1beta2 transition requires
HCloudRemediationto expose v1beta2 conditions in parallel so that tooling and other controllers can consume the new condition format.The Solution
Follow the same structure used for
HCloudMachine(PR #1935):status.v1beta2.conditionstoHCloudRemediation.v1beta2conditions.Set(...)calls in the same controller code paths that already set the v1beta1 conditions.HCloudRemediationScope.Close()to compute:ReadysummaryThis keeps the behavior explicit at each reconcile decision point and avoids a second translation layer that can drift from the real lifecycle logic.
Final Conditions
The final v1beta2 conditions added for
HCloudRemediationare:HCloudRemediationReadyV1Beta2Conditionclusterv1.ReadyV1Beta2ConditionHCloudTokenAvailableV1Beta2ConditionHCloudTokenAvailableHCloudRateLimitExceededV1Beta2ConditionHCloudRateLimitExceeded