v1beta2 contract: stop setting FailureReason/FailureMessage, rework HasFailed()

[damdo]

Parent: #5448

The v1beta2 contract drops terminal error support. Controllers should stop computing and setting FailureReason/FailureMessage. These fields move to status.deprecated.v1beta1 in the v1beta3 types (handled by SUB9), but the controller logic that sets them and depends on them must also change.

Setter call sites to remove (~14 in production code)

File	What it sets	Notes
controllers/awsmachine_controller.go	FailureReason, FailureMessage	Undefined/terminated instance states
pkg/cloud/services/ec2/instances.go	FailureReason, FailureMessage	Missing AMI ID
pkg/cloud/services/eks/cluster.go	FailureMessage (has // TODO FailureReason)	EKS cluster in Failed state
pkg/cloud/services/eks/nodegroup.go	FailureMessage (has // TODO FailureReason)	Nodegroup in CreateFailed/DeleteFailed
pkg/cloud/services/eks/fargate.go	FailureReason, FailureMessage	Fargate profile failed
controlplane/rosa/controllers/rosacontrolplane_controller.go	FailureMessage	ROSA cluster in Error state

HasFailed() control flow to rework

HasFailed() is defined on both MachineScope (pkg/cloud/scope/machine.go) and MachinePoolScope (pkg/cloud/scope/machinepool.go). It returns true if either field is non-nil and is used for early-exit in reconciliation:

• controllers/awsmachine_controller.go — 3 call sites: skips reconciliation, guards secret cleanup
• exp/controllers/awsmachinepool_controller.go — 1 call site: skips reconciliation

Migration: Replace HasFailed() with a check on a condition (e.g., check for a Ready condition with Status=False and a terminal reason). The exact pattern depends on how CAPI core handles this — check CAPV's approach.

SetFailureReason/SetFailureMessage scope helpers to remove

• pkg/cloud/scope/machine.go — SetFailureReason(), SetFailureMessage()
• pkg/cloud/scope/machinepool.go — SetFailureReason(), SetFailureMessage()

During the transition, these should still populate the deprecated fields for backward compat, but new condition-based signaling should be the primary mechanism.

[kubernetes-prow]

This issue is currently awaiting triage.

If CAPA/CAPI contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.