feat: upgrade cluster-api to v1.9.11 with v1beta2 conditions

[schegi]

Summary

• Bumps sigs.k8s.io/cluster-api v1.8.12 → v1.9.11, controller-runtime v0.18.7 → v0.19.6, and k8s.io packages v0.30.x → v0.31.3
• Adopts v1beta2 conditions API on both IonosCloudCluster and IonosCloudMachine (new V1Beta2 status field + GetV1Beta2Conditions/SetV1Beta2Conditions methods); migrates all 6 v1beta1 call sites
• Removes deprecated sigs.k8s.io/cluster-api/errors usage (FailureReason/FailureMessage fields and dead HasFailed() code)
• Fixes predicate signatures (ResourceNotPaused, ClusterUnpaused now require scheme argument)
• Updates e2e config CAPI component URLs to v1.9.11

Test Plan

• Bump cluster-api v1.8.12 → v1.9.11 and controller-runtime v0.18.7 → v0.19.6
• Add v1beta2 conditions API (V1Beta2 status field + Get/SetV1Beta2Conditions) to IonosCloudCluster and IonosCloudMachine
• Remove deprecated FailureReason/FailureMessage fields and dead HasFailed() code
• Migrate all conditions call sites from v1beta1 (MarkTrue/MarkFalse) to v1beta2 (conditions.Set)
• Fix predicate signatures (ResourceNotPaused, ClusterUnpaused now require scheme argument)
• Regenerate deepcopy and CRD manifests
• Update e2e config CAPI component URLs to v1.9.11
• Add meaningful Message fields to conditions.Set calls (CAPI v1beta2 best practice)

Merge

3 PRs in total (merge in that order, maybe release inbetween):

1. v1.8 -> v1.9, this PR
2. v1.9 -> v1.10 feat: upgrade cluster-api to v1.10.10 #353
3. v1.10 -> v1.11 chore: upgrade cluster-api to v1.11.7 #354

[schegi]

@copilot review this PR

[Copilot]

@copilot review this PR

I reviewed the PR. The upgrade is correctly implemented — all CI checks pass (Lint, Test, Verify, Build, Container Image, Codespell, License), and all unit/integration tests pass.

Changes reviewed:

• ✅ sigs.k8s.io/cluster-api v1.8.12 → v1.9.11, controller-runtime v0.18.7 → v0.19.6, k8s.io packages v0.30.x → v0.31.3
• ✅ v1beta2 conditions API correctly added (V1Beta2 status field + GetV1Beta2Conditions/SetV1Beta2Conditions) to both IonosCloudCluster and IonosCloudMachine
• ✅ All 4 v1beta1 call sites correctly migrated from MarkTrue/MarkFalse to conditions.Set with metav1.Condition
• ✅ Deprecated FailureReason/FailureMessage fields and dead HasFailed() code correctly removed
• ✅ Predicate signatures correctly fixed (ResourceNotPaused, ClusterUnpaused now accept a scheme argument)
• ✅ importas alias for sigs.k8s.io/cluster-api/util/conditions/v1beta2 properly configured
• ✅ CRD manifests correctly regenerated with v1beta2 conditions nested object and failureReason/failureMessage removed
• ✅ e2e config URLs updated to v1.9.11

One improvement applied (commit 4b756f2): The conditions.Set calls were missing the Message field. Per CAPI v1beta2 conventions (and mirroring how CAPI core itself always populates this field), I added descriptive messages:

• "Cluster infrastructure is ready" for ClusterReady=True
• "Waiting for cluster infrastructure to become ready" for MachineProvisioned=False
• "Waiting for bootstrap data to become available" for MachineProvisioned=False
• "Machine has been provisioned successfully" for MachineProvisioned=True

Note on backward compatibility: The v1beta1 Status.Conditions field is kept in the API but is no longer populated by the controllers (v1beta2 conditions are used exclusively). Existing v1beta1 conditions on clusters/machines will be cleared on the next reconcile after upgrade, as the patch helper still owns ReadyCondition (v1beta1) via WithOwnedConditions. This is an intentional migration design — worth documenting in the PR or a migration guide.

[piepmatz]

As all this v1beta1 vs v1beta2 is quite a hassle, I read through https://github.com/kubernetes-sigs/cluster-api/blob/4a2e16a3d71d99a923b1f7f3a3efe03c299665fb/docs/proposals/20240916-improve-status-in-CAPI-resources.md.

this proposal is not going to change the fact that the Cluster API contract does not require providers to implement conditions

We have and want conditions, but good to point that out again.

Each provider can implement changes described in the following paragraphs at its own pace, but the transition must be completed before v1beta1 removal (tentative Aug 2026). [...] Starting from the CAPI release when v1beta1 removal will happen (tentative Aug 2026), providers which are implementing the v1beta1 contract will stop to work (they will work only with older versions of Cluster API).

That's soon.

Providers implementing conditions won't be required to do the transition from custom Cluster API Condition type to Kubernetes metav1.Conditions type (but this transition is recommended because it improves the consistency of each provider with Kubernetes, Cluster API and the ecosystem). [...] However, providers choosing to keep using Cluster API custom conditions should be aware that starting from the CAPI release when v1beta1 removal will happen (tentative Aug 2026), the Cluster API project will remove the Cluster API condition type, the util/conditions package, the code handling conditions in util/patch.Helper and everything related to the custom Cluster API v1beta.Condition type. (in other words, Cluster API custom condition must be replaced by provider's own custom conditions).

So even the transition is optional. But we want the transition, of course.

The V1Beta2 struct is going to be added to in v1beta1 types in order to provide a preview of changes coming with the v1beta2 types, but without impacting the semantic of existing fields. Fields in the V1Beta2 will be promoted to status top level fields in the v1beta2 types.

A preview is nice. And CAPI shipped it long before that v1beta2 switch, so it made sense.

The Deprecated struct is going to exist in v1beta2 types only until v1beta1 removal (9 months or 3 minor releases after v1beta2 is released/v1beta1 is deprecated, whichever is longer). Fields in this struct are used for supporting down conversions, thus providing users relying on v1beta1 APIs additional buffer time to pick up the new changes.

So going the same way as CAPI would not only require us to add that V1Beta2 struct, but even a Deprecated one later on. You added it in #354 for CAPI 1.11.

the contract only defines expected names for fields in a resources at YAML/JSON level

The name of the conditions field doesn't change between v1beta1 and v1beta2, just the severity is removed and the reason field will be required.

Given that

• as an infrastructure provider we are not bound to any condition contract
• a preview doesn't make sense anymore with only few months remaining till August
• the difference between v1beta1 and v1beta2 conditions is quite small on the JSON level

I propose we keep it simple and just change the conditions to v1beta2/metav1 directly, without any intermediate steps. That has also worked fine in one of our internal projects when updating the CAPI libs to v1.10.

We bump our minor version, point it out in the release notes and that's it.

[schegi]

@copilot Review

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Please also update the README at https://github.com/ionos-cloud/cluster-api-provider-ionoscloud?tab=readme-ov-file#cluster-api-versions

Done in commit e1f4784. Added a new column for Cluster API v1.9 and a new row for CAPIC v0.7 to the compatibility table.

@copilot Review

Review complete. The PR is in good shape. Here's a summary of the current state:

Dependencies:

• ✅ sigs.k8s.io/cluster-api v1.9.11 (latest v1.9.x patch)
• ✅ sigs.k8s.io/controller-runtime v0.19.7 (latest v0.19.x patch, just bumped in e1f4784)
• ✅ k8s.io/api|apimachinery|client-go v0.31.14 (latest v0.31.x patch)

Conditions migration:

• ✅ Status.Conditions flattened to []metav1.Condition in both IonosCloudCluster and IonosCloudMachine — no nested V1Beta2 struct, no dual-write
• ✅ Only GetV1Beta2Conditions/SetV1Beta2Conditions interface methods are implemented (v1beta1 GetConditions/SetConditions removed)
• ✅ All condition write sites use conditions.Set with metav1.Condition (v1beta2 package only)
• ✅ SetSummaryCondition uses clusterv1.ReadyV1Beta2Condition; patch helper uses only WithOwnedV1Beta2Conditions

Cleanup:

• ✅ FailureReason/FailureMessage fields and HasFailed() removed
• ✅ Predicate signatures fixed (ResourceNotPaused, ClusterUnpaused with scheme)
• ✅ CRD manifests regenerated with metav1.Condition schema (listType=map, listMapKey=type)
• ✅ deepcopy regenerated correctly

Tests:

• ✅ All unit tests pass; ionoscloudmachine_types_test.go and ionoscloudcluster_types_test.go updated to use v1beta2 API and test GetV1Beta2Conditions/SetV1Beta2Conditions

README:

• ✅ CAPI versions table updated with CAPIC v0.7 / CAPI v1.9 row (commit e1f4784)

One minor note: the go.mod has go 1.25.0 (with patch) while the Dockerfile and image.yaml may reference a slightly different Go version — not a blocking issue for this PR.

[piepmatz]

For the record: We decided to shuffle the PRs a bit. The update to CAPI v1.9 will be extracted from the PR, so that we'll have only the switch of the conditions to metav1 plus the corresponding helpers from the v1beta2 packages in here.

Merge and tag order will be the following then:

• Bump CAPI to v1.9 (PR to be created)
• Bump CAPI to v1.10 and adopt the CRD migrator (feat: upgrade cluster-api to v1.10.10 #353)
• Create tag v0.6.4.
• Switch conditions to metav1 (this PR)
• Bump CAPI to v1.11 and comply with the v1beta2 contract. Also switch import paths for v1beta2 conditions accordingly. (chore: upgrade cluster-api to v1.11.7 #354)
• Bump to CAPI v1.12 (chore: upgrade cluster-api to v1.12.4 #356)
• Create tag v0.7.0