🌱 Bump CAPI to v1.12.2, k8s to v1.34 and controller-runtime to v0.22.5#5857
Open
clebs wants to merge 18 commits intokubernetes-sigs:mainfrom
Open
🌱 Bump CAPI to v1.12.2, k8s to v1.34 and controller-runtime to v0.22.5#5857clebs wants to merge 18 commits intokubernetes-sigs:mainfrom
clebs wants to merge 18 commits intokubernetes-sigs:mainfrom
Conversation
k8s-ci-robot
added
release-note
Contributor
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
k8s-ci-robot
added
the
size/L
richardcase
requested changes
Feb 3, 2026
Member
richardcase
left a comment
richardcase
left a comment
There was a problem hiding this comment.
@clebs - we'll also need to update the CAPI version in other places like the e2e config files. Like this: https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/main/test/e2e/data/e2e_conf.yaml#L30
k8s-ci-robot
added
size/XL
Member
Author
|
/ok-to-test |
k8s-ci-robot
added
the
ok-to-test
Member
Author
@richardcase I have updated CAPI and k8s versions based on previous bump PRs:
PTAL! |
clebs
force-pushed
the
capi-1.12-bump
branch
2 times, most recently
from
b6a0781 to
b06184d
Compare
Member
Author
|
/retest |
1 similar comment
Member
Author
|
/retest |
5 tasks
k8s-ci-robot
added
needs-rebase
Member
|
/test pull-cluster-api-provider-aws-e2e-blocking |
Member
Author
|
/test pull-cluster-api-provider-aws-e2e-blocking |
Member
Member
|
@clebs this will need rebasing, then we can retest and see |
Member
Author
|
/test pull-cluster-api-provider-aws-e2e |
Member
Author
|
/test pull-cluster-api-provider-aws-e2e-eks |
Member
Author
|
/retest |
Contributor
|
/test pull-cluster-api-provider-aws-e2e-eks |
Member
Author
|
/retest |
Member
|
/test pull-cluster-api-provider-aws-e2e |
2 similar comments
Member
|
/test pull-cluster-api-provider-aws-e2e |
Member
Author
|
/test pull-cluster-api-provider-aws-e2e |
Contributor
|
@clebs: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions 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. I understand the commands that are listed here. |
- Update cluster-api to v1.12.2 - Update kubernetes depencencies to v0.34.3: - k8s.io/api - k8s.io/apiextensions-apiserver - k8s.io/apimachinery - k8s.io/client-go - k8s.io/component-base - Update controller-runtime to v0.22.5 - Update ginkgo to v2.27.2 - Update gomega to v1.38.2 - Regenerate base CRDs Signed-off-by: Borja Clemente <bclement@redhat.com>
Signed-off-by: Borja Clemente <bclement@redhat.com>
Signed-off-by: Borja Clemente <bclement@redhat.com>
Signed-off-by: Borja Clemente <bclement@redhat.com>
Signed-off-by: Borja Clemente <borja.clemente@gmail.com>
As we update to kubernetes 1.33+ and introduce the AMI AL2023 templates, we need to use the NodeadmConfig instead of EKSConfig for bootstrapping. Signed-off-by: Borja Clemente <borja.clemente@gmail.com>
* test: fix mmp tests * fix(e2e): remove check to use old secret generation method because templates always use nodeadm now * fix: remove field cloud init field for machinepool * fix(e2e): adds al2023 explictly for AMI type
* feat: convert default eks templates to use nodeadm by default * test: removes redundant nodeadm test
Background diagnostic goroutines (resource dump every 5s, machine dump every 60s) call upstream CAPI framework functions (DumpAllResources, DumpMachines) that use Gomega Expect() assertions internally. When a cluster is being deleted, these assertions can fail with "not found" errors. Since these dumps are purely informational, their failures should not mark the test spec as failed or cause panics. The previous fix used InterceptGomegaFailure() to catch these failures, but that function is not goroutine-safe: it temporarily replaces the global Gomega fail handler, which can race with assertions in the test's main goroutine. This caused [PANICKED] failures when Eventually() timeouts in the test goroutine hit the intercepted handler, which panics with "stop execution" instead of calling ginkgo.Fail(). Replace InterceptGomegaFailure with a goroutine-aware custom fail handler registered via RegisterFailHandler. The handler uses a sync.Map to track diagnostic goroutine IDs. When a Gomega assertion fails: - In a diagnostic goroutine: panic with a sentinel value (without ever calling ginkgo.Fail), caught by a per-call recover() which logs a warning. - In any other goroutine: delegate to ginkgo.Fail normally. This ensures diagnostic dump failures are silently absorbed without affecting global state or racing with test assertions. Ref: https://kubernetes.slack.com/archives/CD6U2V71N/p1758795545213209
…duling During self-hosted e2e tests, the CAPA controller pod can be evicted from a control plane node during upgrade drain and rescheduled to a worker node. The previous gcr.io/k8s-staging-cluster-api/capa-manager:e2e image reference is a local-only tag that doesn't exist on any registry, so if the kubelet garbage-collects the pre-loaded image, the pod enters ImagePullBackOff permanently. Fix this by dynamically rewriting the CAPA provider component image replacement to use the ECR Public URL (where the image is already pushed by ensureTestImageUploaded). With imagePullPolicy: IfNotPresent, the kubelet uses the local cache when available and falls back to pulling from ECR Public if needed. The ECR-tagged image is also added to the Kind bootstrap images list for consistency.
…it race Lower the healthy threshold from 5 to 2 and the health check interval from 10s to 5s, reducing the time for the target group to mark the API server as healthy from 50s to 10s. This leaves a comfortable 50s margin within kubeadm's default 60s kubernetesAPICallTimeout, preventing the upload-config/kubeadm phase from hitting a context deadline when the ELB has not yet started forwarding traffic. Also increase the unhealthy threshold from 3 to 6 to compensate for the shorter interval and avoid flapping during transient hiccups.
Add a new `DNSResolutionCheck` field to AWSLoadBalancerSpec that allows users to control whether the provider verifies DNS resolution of the API server LB before marking the load balancer as ready and setting the control plane endpoint. By default (when unset), the DNS lookup is performed So this check is now made by default as it is necessary to have a fully ready and routable load balancer before proceeding further with the cluster bootstrapping. This has now become a strict prerequisite for CAPI clusters being installed and bootrapped via the CAPI KubeAdm bootstrap provider, given the recent changes to make this a stricter requirement that have been introduced by kubeadm (see: kubernetes/kubeadm#3294) Setting the field to "None" skips the check entirely, which is useful in environments with no kubeadm requirements, slow DNS propagation, custom resolvers, or private hosted zones where the controller node may not be able to resolve the ELB's FQDN despite it being valid.
…ration Introduce PendingInstanceRequeue (1s) to replace DefaultReconcilerRequeue (30s) for the pending-instance polling loop. This reduces the worst-case delay between an EC2 instance reaching Running state and the controller registering it with the API server NLB target group. AWS NLB target registration has an internal propagation delay of 90–180s before health checks begin and traffic is routed. With the previous 30s requeue, the total time from instance creation to NLB readiness left insufficient margin for kubeadm's 60-second upload-config timeout. Measured CI timelines showed failures missing the deadline by only 2–24s; polling every 1s instead of 30s recovers ~29s of that margin, shifting most clusters from failure to success.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
/kind support
What this PR does / why we need it:
This PR bumps CAPI to v1.12.2 and with it, k8s to v1.34.3 and controller-runtime to v0.22.5.
Needed to be up to date with CAPI releases.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #5834
Special notes for your reviewer:
None
TODO
This bump is affected by the following issues which needs to be addressed before we can successfully see this bump passing regular e2es:
Checklist:
Release note: