NO-JIRA: chore(deps): weekly dependabot consolidation

[hypershift-jira-solve-ci]

Summary

Weekly consolidation of dependabot dependency updates.

Consolidated PRs

• build(deps): bump github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azkeys from 1.4.0 to 1.5.0 in the azure-github-dependencies group across 1 directory #8629: build(deps): bump github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azkeys from 1.4.0 to 1.5.0 in the azure-github-dependencies group
• fix(deps): bump urllib3 from 2.6.3 to 2.7.0 in /hypershift-ci-python #8482: fix(deps): bump urllib3 from 2.6.3 to 2.7.0 in /hypershift-ci-python

Commits

1. chore(deps): update root module dependencies
2. chore(deps): update vendored dependencies

---

Assisted-by: Claude (via Claude Code)

---

Note: This PR was auto-generated by the dependabot-triage periodic CI job. See the full report for token usage, cost breakdown, and detailed output.

Summary by CodeRabbit

• Chores
  • Updated Azure Key Vault Keys SDK dependency to v1.5.0.
  • No changes to public APIs or exported interfaces; behavior remains compatible.
  • Routine dependency maintenance with no user-facing feature changes or regressions expected.

[openshift-merge-bot]

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

[openshift-ci-robot]

@hypershift-jira-solve-ci[bot]: This pull request explicitly references no jira issue.

Details

In response to this:

Summary

Weekly consolidation of dependabot dependency updates.

Consolidated PRs

• build(deps): bump github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azkeys from 1.4.0 to 1.5.0 in the azure-github-dependencies group across 1 directory #8629: build(deps): bump github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azkeys from 1.4.0 to 1.5.0 in the azure-github-dependencies group
• fix(deps): bump urllib3 from 2.6.3 to 2.7.0 in /hypershift-ci-python #8482: fix(deps): bump urllib3 from 2.6.3 to 2.7.0 in /hypershift-ci-python

Commits

1. chore(deps): update root module dependencies
2. chore(deps): update vendored dependencies

---

Assisted-by: Claude (via Claude Code)

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 openshift-eng/jira-lifecycle-plugin repository.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 875e271d-fb74-4b41-a79d-b06fe4dc3a72

📥 Commits

Reviewing files that changed from the base of the PR and between 230172e and fad2e82.

⛔ Files ignored due to path filters (1)

• go.sum is excluded by !**/*.sum

📒 Files selected for processing (1)

• go.mod

🚧 Files skipped from review as they are similar to previous changes (1)

• go.mod

---

📝 Walkthrough

Walkthrough

This PR updates the Azure Key Vault SDK dependency in the HyperShift repository from v1.4.0 to v1.5.0. The change modifies a single line in go.mod to reference the newer version of the github.com/Azure/azure-sdk-for-go/sdk/security/keyvault/azkeys package. No other module requirements, replace directives, or code changes are included.

Suggested reviewers

• sjenning
• bryan-cox

🚥 Pre-merge checks | ✅ 11

✅ Passed checks (11 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the pull request as a weekly dependabot consolidation of dependency updates, which matches the PR's main objective and the changeset content.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names	✅ Passed	All Ginkgo test titles use stable, static descriptive strings without dynamic values (UUIDs, timestamps, node names, IP addresses, generated identifiers).
Test Structure And Quality	✅ Passed	The PR contains only dependency version bumps (Azure SDK azkeys v1.4.0 → v1.5.0) and vendor updates; no test code was created or modified, making the Ginkgo test quality check not applicable.
Topology-Aware Scheduling Compatibility	✅ Passed	PR is a dependency version bump (go.mod update) with no new deployment manifests, operator code, or controller modifications that introduce scheduling constraints.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	No Ginkgo e2e tests were added. All 37 new test files use standard Go testing (testing.T), not Ginkgo (It/Describe patterns). Check only applies to Ginkgo tests.
No-Weak-Crypto	✅ Passed	No weak cryptography detected. PR only bumps Azure SDK dependency (azkeys v1.4.0→v1.5.0) with vendoring updates. No MD5, SHA1, DES, RC4, 3DES, Blowfish, ECB, or custom crypto implementations found.
Container-Privileges	✅ Passed	PR only updates Go module dependencies (azkeys v1.4.0→v1.5.0) with no changes to K8s container manifests or privilege configurations.
No-Sensitive-Data-In-Logs	✅ Passed	PR contains only dependency version bumps (go.mod/go.sum) and vendor updates; no logging statements that expose passwords, tokens, API keys, PII, or other sensitive data were added.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 41.41%. Comparing base (b593a02) to head (fad2e82).
⚠️ Report is 17 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8634   +/-   ##
=======================================
  Coverage   41.41%   41.41%           
=======================================
  Files         756      756           
  Lines       93623    93623           
=======================================
  Hits        38777    38777           
  Misses      52120    52120           
  Partials     2726     2726           

Flag	Coverage Δ
cmd-support	34.87% <ø> (ø)
cpo-hostedcontrolplane	43.50% <ø> (ø)
cpo-other	42.79% <ø> (ø)
hypershift-operator	51.48% <ø> (ø)
other	31.64% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bryan-cox]

/retest
/area hypershift-operator

[bryan-cox]

/cc @bryan-cox

[bryan-cox]

/lgtm

[openshift-merge-bot]

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aks
/test e2e-aws
/test e2e-aws-upgrade-hypershift-operator
/test e2e-azure-self-managed
/test e2e-kubevirt-aws-ovn-reduced
/test e2e-v2-aws
/test e2e-v2-gke

[hypershift-jira-solve-ci]

AI Test Failure Analysis

Job: pull-ci-openshift-hypershift-main-e2e-azure-self-managed | Build: 2060403953098559488 | Cost: $ | Failed step: hypershift-azure-run-e2e-self-managed

View full analysis report

---

_{Generated by hypershift-analyze-e2e-failure post-step using Claude claude-opus-4-6}

[cwbotbot]

Test Results

e2e-aks

• Status: ✅ PASS
• Started: 2026-06-04T13:46:01Z
• View Job
• View Job History

e2e-aws

• Status: ✅ PASS
• Started: 2026-06-04T19:29:02Z
• View Job
• View Job History

[bryan-cox]

/retest

[bryan-cox]

/override codecov/project

[openshift-ci]

@bryan-cox: Overrode contexts on behalf of bryan-cox: codecov/project

Details

In response to this:

/override codecov/project

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.

[bryan-cox]

/approve
/lgtm
/verified by e2e

[openshift-ci-robot]

@bryan-cox: This PR has been marked as verified by e2e.

Details

In response to this:

/approve
/lgtm
/verified by e2e

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-merge-bot]

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aks
/test e2e-aws
/test e2e-aws-upgrade-hypershift-operator
/test e2e-azure-self-managed
/test e2e-azure-v2-self-managed
/test e2e-kubevirt-aws-ovn-reduced
/test e2e-v2-aws
/test e2e-v2-gke

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bryan-cox, hypershift-jira-solve-ci[bot]

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [bryan-cox]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[hypershift-jira-solve-ci]

AI Test Failure Analysis

Job: pull-ci-openshift-hypershift-main-e2e-aks | Build: 2062495778970013696 | Cost: $4.347215 | Failed step: hypershift-azure-run-e2e

View full analysis report

---

_{Generated by hypershift-analyze-e2e-failure post-step using Claude claude-opus-4-6}

[bryan-cox]

/test e2e-aks

[bryan-cox]

/test e2e-aws

[openshift-merge-bot]

/retest-required

Remaining retests: 0 against base HEAD 8866daf and 2 for PR HEAD fad2e82 in total

[hypershift-jira-solve-ci]

I now have all the evidence. Let me compile the final analysis:

Test Failure Analysis Complete

Job Information

• Prow Job: pull-ci-openshift-hypershift-main-e2e-aws
• Build ID: 2062542262943879168
• Target: e2e-aws
• Test: TestKarpenterUpgradeControlPlane/ValidateHostedCluster
• PR: NO-JIRA: chore(deps): weekly dependabot consolidation #8634 (NO-JIRA: chore(deps): weekly dependabot consolidation)

Test Failure Analysis

Error

util.go:583: Failed to wait for 2 nodes to become ready in 45m0s: context deadline exceeded
eventually.go:384: observed invalid **v1.Node state after 45m0s
eventually.go:401:  - observed **v1.Node collection invalid: expected 2 nodes, got 1

Summary

The TestKarpenterUpgradeControlPlane test failed because one of the two EC2 instances provisioned for the hosted cluster's initial NodePool (replicas=2) was unable to complete its Ignition bootstrap. The second machine (swj4k) was stuck in an infinite Ignition fetch loop, repeatedly failing to reach the AWS Instance Metadata Service (IMDS) at 169.254.169.254:80 with "network is unreachable" errors for the entire duration of the test (71+ attempts over 5+ minutes of captured console output, likely continuing for the full 45-minute wait). Because this machine never bootstrapped, only 1 of the expected 2 nodes became Ready, causing a context deadline timeout. The first machine (pbndc) booted normally and joined the cluster successfully. This is an AWS infrastructure-level issue — the second EC2 instance's network was misconfigured or not yet ready when Ignition tried to contact IMDS — and is unrelated to the dependabot dependency consolidation changes in the PR.

Root Cause

The root cause is an AWS EC2 infrastructure issue where the second provisioned machine (karpenter-upgrade-control-plane-ldpvq-us-east-1c-qpqtv-swj4k) could not reach the AWS Instance Metadata Service (IMDS) at 169.254.169.254. The Ignition service on this machine requires IMDS to fetch its configuration token via PUT http://169.254.169.254/latest/api/token (IMDSv2 token-based access), but every attempt returned dial tcp 169.254.169.254:80: connect: network is unreachable.

Key details:

• The machine's network stack was not correctly configured or initialized, preventing access to the link-local IMDS endpoint
• This is a transient AWS infrastructure issue — the IMDS endpoint is a link-local address that should always be reachable from within the EC2 instance once basic networking is up
• The error persisted for the entire capture window (71 attempts, from ~1m29s to ~5m37s of boot time), indicating the network never recovered
• The first machine (pbndc) booted normally with Ignition succeeding on its first run (console log shows Ignition: ran on 2026/06/04 16:13:22 UTC and Ignition: user-provided config was applied)
• Both machines were in the same MachineSet (qpqtv) and same availability zone (us-east-1c), ruling out zone-level issues
• The hosted cluster only ever had 1 node registered (confirmed by the cluster-scoped resources dump showing only ip-10-0-135-221.ec2.internal)

This failure is NOT related to the PR changes (dependabot dependency consolidation). The PR modifies only vendored Go dependencies and does not touch test code, Karpenter logic, or infrastructure provisioning. This is a well-known class of transient AWS infrastructure flake where IMDS becomes unreachable during early boot.

Recommendations

1. Retry the CI job — This is a transient AWS infrastructure issue (IMDS unreachable during EC2 boot). A retry should succeed since the first machine and all other tests in the same run passed normally.

2. No code changes needed — The PR's dependabot changes are unrelated to this failure. The test infrastructure, Karpenter logic, and node provisioning code are not at fault.

3. Consider filing an AWS infrastructure flake tracking issue if this pattern recurs — IMDS network unreachability during early boot is a known AWS edge case that could benefit from:

   • Longer Ignition retry timeouts or backoff strategies
   • A machine health check that replaces instances stuck in Ignition fetch

4. The TestKarpenterUpgradeControlPlane test itself is functioning correctly — it properly detected that only 1 of 2 expected nodes was ready and failed after the 45-minute timeout, which is the expected behavior when a machine fails to bootstrap.

Evidence

Evidence	Detail
Failed test	TestKarpenterUpgradeControlPlane/ValidateHostedCluster — timed out waiting for 2 nodes, only 1 became ready
NodePool config	karpenter-upgrade-control-plane-ldpvq-us-east-1c with replicas: 2 (from manifests.yaml)
Working machine (pbndc)	Booted normally; Ignition succeeded at 16:13:22 UTC; console log shows OVS configuration and Ignition: user-provided config was applied
Failing machine (swj4k)	Stuck in Ignition fetch loop; 71+ attempts to reach IMDS at 169.254.169.254:80 all returned network is unreachable
IMDS error	PUT error: Put "http://169.254.169.254/latest/api/token": dial tcp 169.254.169.254:80: connect: network is unreachable
Hosted cluster dump	Only 1 node (ip-10-0-135-221.ec2.internal) present in cluster-scoped-resources; node was Ready and from NodePool karpenter-upgrade-control-plane-ldpvq-us-east-1c
Wait duration	45 minutes (test timeout for node readiness)
Other tests	614 of 616 tests passed; all other hosted clusters provisioned successfully in the same run
PR changes	Dependabot dependency consolidation (vendor-only changes) — no test, infra, or Karpenter code modified

---

[openshift-merge-bot]

/retest-required

Remaining retests: 0 against base HEAD 38f7b17 and 1 for PR HEAD fad2e82 in total

[bryan-cox]

/verified by e2e

[openshift-ci-robot]

@bryan-cox: This PR has been marked as verified by e2e.

Details

In response to this:

/verified by e2e

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

@hypershift-jira-solve-ci[bot]: all tests passed!

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.