MachineSet created exactly at spec.rollout.after timestamp is incorrectly marked as not up-to-date

[arno-pons]

What steps did you take and what happened?

Testing the rollout machinedeployment feature of clusterctl i have notived that when a MachineSet's metadata.creationTimestamp equals exactly the MachineDeployment's spec.rollout.after time, the MachineSet is incorrectly marked as not up-to-date, causing the MachineDeployment RollingOut status to keep the True value forever.

This seems to be a boundary condition bug in the timestamp comparison logic:

cluster-api/internal/controllers/machineset/machineset_controller.go

Line 639 in 5226d3f

if s.owningMachineDeployment.Spec.Rollout.After.Time.Before(s.reconciliationTime) && !s.machineSet.CreationTimestamp.After(s.owningMachineDeployment.Spec.Rollout.After.Time) {

when timestamps are equal (in that case the after() will false).
I suppose that using the before() function could help to resolve the issue here.

What did you expect to happen?

MachineDeployment to have a correct RollingOut status type.

Cluster API version

v1.11.4

Kubernetes version

v1.34.3

Anything else you would like to add?

Output showing the issue:

k get ms k8s-ppi-md-0-fqqrs-bmsxw                                                                                                                                                                                                                        
NAME                       CLUSTER   DESIRED   CURRENT   READY   AVAILABLE   UP-TO-DATE   AGE   VERSION
k8s-ppi-md-0-fqqrs-bmsxw   k8s-ppi   1         1         1       1           0            71m   v1.34.3

k get ms k8s-ppi-md-0-fqqrs-bmsxw -o jsonpath='{"creationTimestamp:"}{.metadata.creationTimestamp}{"\n"}{"MachinesUpToDate:"}{.status.conditions[?(@.type=="MachinesUpToDate")]}{"\n"}{"owner md:"}{.metadata.ownerReferences[?(@.kind=="MachineDeployment")].name}'
creationTimestamp:2025-12-22T14:11:22Z
MachinesUpToDate:{"lastTransitionTime":"2025-12-22T14:11:25Z","message":"* Machine k8s-ppi-md-0-fqqrs-bmsxw-67b7f:\n  * MachineDeployment spec.rolloutAfter expired","observedGeneration":1,"reason":"NotUpToDate","status":"False","type":"MachinesUpToDate"}
owner md:k8s-ppi-md-0-fqqrs

k get md k8s-ppi-md-0-fqqrs
NAME                 CLUSTER   AVAILABLE   DESIRED   CURRENT   READY   AVAILABLE   UP-TO-DATE   PHASE     AGE     VERSION
k8s-ppi-md-0-fqqrs   k8s-ppi   True        1         1         1       1           0            Running   5d23h   v1.34.3

k get md k8s-ppi-md-0-fqqrs -o jsonpath='{"rolloutAfter:"}{.spec.rollout.after}{"\n"}{"RollingOut:"}{.status.conditions[?(@.type=="RollingOut")]}{"\n"}'
rolloutAfter:2025-12-22T14:11:22Z
RollingOut:{"lastTransitionTime":"2025-12-22T14:11:23Z","message":"Rolling out 1 not up-to-date replicas\n* MachineDeployment spec.rolloutAfter expired","observedGeneration":12,"reason":"RollingOut","status":"True","type":"RollingOut"}

Label(s) to be applied

/kind bug
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[fabriziopandini]

/help

[k8s-ci-robot]

@fabriziopandini:
This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-help command.

Details

In response to this:

/help

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.