Cluster API (CAPI) v1.13.x bump - (Potential) UI Impact

[snasovich]

This is just a placeholder issue for any UI issues that may happen due to CAPI bump to v1.13.x to be done per rancher/rancher#54304
At this point the impact of this bump is not expected to be big as there is no CAPI API version change between v1.12 and v1.13 (unlike v1.10 to v1.11 when API version changed from v1beta1 to v1beta2).

[github-actions]

🎯 Agentic Issue Triage

This is a placeholder/tracking issue for potential UI regressions caused by the CAPI (Cluster API) bump from v1.12.x → v1.13.x, as part of rancher/rancher#54304. The author notes the impact is expected to be minimal since no CAPI API version change occurred (unlike the v1beta1→v1beta2 change from v1.10→v1.11).

📋 Issue Summary & Context

• Type: Tracking / Placeholder issue
• Milestone: v2.15.0
• Area: CAPI provisioning UI (area/capi, area/clusterprovisioningv2)
• Team: area2 (Hostbusters)
• Upstream reference: Cluster API (CAPI) v1.13.x bump rancher#54304
• Since there is no API version change (v1beta2 is still used), most cluster provisioning flows should remain unaffected. However, new or changed CAPI v1.13 fields, defaulting behavior, or controller behavior changes could surface in the UI.

🔍 Suggested Areas to Investigate

• CAPI v1.13 changelog: Review sigs.k8s.io/cluster-api releases for v1.13.x to identify any schema or behavioral changes that could affect the Rancher UI.
• MachineDeployment / MachineSet fields: Check if any new optional/required fields were added that the UI doesn't surface or validate.
• ClusterClass: Any changes to ClusterClass topology fields that could affect the provisioning forms.
• Status conditions: New or renamed status condition types may affect health indicators displayed in the UI.
• RBAC / webhook changes: Any new webhook validations in CAPI v1.13 that could cause previously valid UI-submitted objects to be rejected.

🧪 Reproduction / Validation Steps

1. Deploy a Rancher instance running the CAPI v1.13.x bump.
2. Provision a new RKE2/K3s cluster using CAPI (ClusterClass-based if applicable).
3. Verify cluster provisioning completes successfully with no UI errors.
4. Edit an existing CAPI-managed cluster — check that fields render correctly.
5. Verify machine pool scaling (up and down) works through the UI.
6. Check cluster detail pages for any missing or broken status/condition displays.
7. Attempt cluster deletion via the UI and confirm no issues.
8. Review browser console for any schema-validation or unknown-field warnings.

🛠️ Debugging Strategies

• Compare kubectl get crds | grep cluster.x-k8s.io schemas between a v1.12 and v1.13 environment to spot field additions/removals.
• Enable Rancher debug logging and watch for any API 422/400 errors when submitting cluster forms.
• Check the shell/ directory for any hardcoded CAPI field references that may need updating (e.g., grep -r "cluster.x-k8s.io" shell/).
• Look for any version-gated code paths in the provisioning components under shell/pages/c/_cluster/ and shell/components/.

✅ Suggested Sub-tasks Checklist

• Review CAPI v1.13.x release notes and changelog for breaking/notable changes
• Test end-to-end cluster provisioning with CAPI v1.13 in a dev environment
• Test cluster editing and machine pool management via the UI
• Test cluster deletion via the UI
• Verify status/condition display on cluster detail page
• Check for any new CRD fields missing from provisioning forms
• Run existing Cypress E2E provisioning tests against a CAPI v1.13 backend
• Update UI code if any new required fields or schema changes are found

Generated by Agentic Triage for issue #17731 · ● 169.9K · ◷