Better UX to indicate the reason of WaitingForInfrastructure when using MachinePool/AzureMachinePool

[MadJlzz]

/kind bug

What steps did you take and what happened: Add a AzureMachinePool to a cluster with a vmSize not available in the MachinePool specified failureDomains.

While monitor the advancement of the pool provisionning with clusterctl, I've noticed that the state was not changing and staying blocked on WaitingForInfrastructure

Describing both MachinePool and AzureMachinePool object gave me no indication that the chosen vmSize was not available in the region/zones I've specified.

Finding the problem required me to check the logs of capz controller.

What did you expect to happen: Have a better explanation on the status of the object to know why we're WaitingForInfrastructure.

Anything else you would like to add: [Miscellaneous information that will assist in solving the issue.]

Environment:

• cluster-api-provider-azure version

  > kg provider -A
  NAMESPACE                           NAME                    AGE   TYPE                     PROVIDER      VERSION
  capa-system                         infrastructure-aws      71d   InfrastructureProvider   aws           v2.3.1
  capi-kubeadm-bootstrap-system       bootstrap-kubeadm       71d   BootstrapProvider        kubeadm       v1.7.2
  capi-kubeadm-control-plane-system   control-plane-kubeadm   71d   ControlPlaneProvider     kubeadm       v1.7.2
  capi-system                         cluster-api             71d   CoreProvider             cluster-api   v1.7.2
  capz-system                         infrastructure-azure    71d   InfrastructureProvider   azure         v1.15.1

• Kubernetes version: (use kubectl version)

  > kubectl version
  Client Version: v1.29.2
  Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
  Server Version: v1.27.12-gke.1115000
  WARNING: version difference between client (1.29) and server (1.27) exceeds the supported minor version skew of +/-1

• OS (e.g. from /etc/os-release): Ubuntu 22.04

[willie-yao]

/priority backlog

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[MadJlzz]

/remove-lifecycle stale