deps(deps): bump k8s-openapi from 0.21.1 to 0.24.0

[dependabot]

Bumps k8s-openapi from 0.21.1 to 0.24.0.

Release notes

Sourced from k8s-openapi's releases.

v0.24.0

k8s-openapi

• BREAKING CHANGE: Added support for Kubernetes 1.32 under the v1_32 feature.

• BREAKING CHANGE: Dropped support for Kubernetes 1.26 and 1.27.

Corresponding Kubernetes API server versions:

• v1.28.15
• v1.29.12
• v1.30.8
• v1.31.4
• v1.32.0

k8s-openapi-codegen-common

• No changes.

k8s-openapi-derive

• No changes except to bump the k8s-openapi-codegen-common dependency to the new version.

v0.23.0

k8s-openapi

• BREAKING CHANGE: Added support for Kubernetes 1.31 under the v1_31 feature.

• BREAKING CHANGE: Dropped support for Kubernetes 1.24 and 1.25.

Corresponding Kubernetes API server versions:

• v1.26.15
• v1.27.16
• v1.28.14
• v1.29.9
• v1.30.5
• v1.31.1

k8s-openapi-codegen-common

• No changes.

k8s-openapi-derive

• No changes except to bump the k8s-openapi-codegen-common dependency to the new version.

v0.22.0

k8s-openapi

... (truncated)

Changelog

Sourced from k8s-openapi's changelog.

v0.24.0 (2024-12-21)

k8s-openapi

• BREAKING CHANGE: Added support for Kubernetes 1.32 under the v1_32 feature.

• BREAKING CHANGE: Dropped support for Kubernetes 1.26 and 1.27.

Corresponding Kubernetes API server versions:

• v1.28.15
• v1.29.12
• v1.30.8
• v1.31.4
• v1.32.0

k8s-openapi-codegen-common

• No changes.

k8s-openapi-derive

• No changes except to bump the k8s-openapi-codegen-common dependency to the new version.

---

v0.23.0 (2024-09-15)

k8s-openapi

• BREAKING CHANGE: Added support for Kubernetes 1.31 under the v1_31 feature.

• BREAKING CHANGE: Dropped support for Kubernetes 1.24 and 1.25.

Corresponding Kubernetes API server versions:

• v1.26.15
• v1.27.16
• v1.28.14
• v1.29.9
• v1.30.5
• v1.31.1

k8s-openapi-codegen-common

• No changes.

k8s-openapi-derive

• No changes except to bump the k8s-openapi-codegen-common dependency to the new version.

... (truncated)

Commits

• 27a69bc v0.24.0
• 1f0f14f Update kind to v0.26.0
• 6a64cac Fix various leftover mentions of k8s-openapi-derive generating API functions.
• 3f16b5e Drop v1.26, v1.27
• 9413a9a Add v1.32.0
• dfcf9ab Fix new clippy lint about unnecessary lifetimes on impl blocks.
• d078091 Update to v1.29.12, v1.30.8, v1.31.4
• b460fff Update to v1.29.11, v1.30.7, v1.31.3
• 7f38ac0 Update kind to v0.25.0
• d2240d4 Update to v1.31.2
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[covenant-talos]

Walkthrough

This Dependabot PR bumps the k8s-openapi dependency in basilica-validator from version 0.21 to 0.24, keeping the v1_29 feature flag. The upstream 0.24 release adds Kubernetes 1.32 support and drops 1.26/1.27. Notably, the lock file now contains two copies of k8s-openapi (0.21.1 and 0.24.0) because kube 0.88 still depends on the older version — the upgrade only applies to basilica-validator's direct dependency, not the transitive one pulled in by kube.

Changes

Cohort / File(s)	Change Summary
Dependency manifest / crates/basilica-validator/Cargo.toml	Bumps direct k8s-openapi version requirement from 0.21 to 0.24, retaining the v1_29 feature.
Lock file / Cargo.lock	Adds k8s-openapi 0.24.0 as a separate entry while kube-pulled 0.21.1 remains; also picks up unrelated windows-sys version bumps across transitive dependencies.

Estimated review effort: 2/5 (version bump, but dual k8s-openapi versions warrant a quick check that no API surface used by basilica-validator changed incompatibly).

Instant overview - a deep technical review follows as a separate comment.

[covenant-talos]

PR #549: deps(deps): bump k8s-openapi from 0.21.1 to 0.24.0

Summary

Dependabot bumps k8s-openapi from 0.21.1 to 0.24.0 in crates/basilica-validator/Cargo.toml, keeping the v1_29 version feature, and updates Cargo.lock accordingly. Because the sibling dependency kube is left at 0.88.1 (which itself requires k8s-openapi 0.21.1), the lockfile now contains two different k8s-openapi versions (0.21.1 for the kube crates, 0.24.0 for basilica-validator). The lockfile also contains unrelated transitive churn (windows-sys 0.59.0 → 0.61.2/0.60.2 across ~9 packages). The bump spans three breaking upstream releases (0.22, 0.23, 0.24), which dropped Kubernetes 1.24–1.27 API support and added 1.31/1.32 support.

Architecture

No structural impact. The change is confined to two manifest files, but kube and k8s-openapi are a version-locked pair in the Rust Kubernetes ecosystem: kube does not select a Kubernetes version feature itself; it relies on Cargo feature unification with the consumer's direct k8s-openapi dependency at the same crate version. This PR breaks that invariant.

Issues Found

CRITICAL Issues (Must Fix Before Merge)

1. Bump kube in lockstep with k8s-openapi — kube 0.88.1 still binds to k8s-openapi 0.21.1, leaving two incompatible copies in the graph
   Functional Correctness | CRITICAL | involved

   • Why: The lockfile diff shows the skew explicitly. basilica-validator now resolves to the new copy (- "k8s-openapi" / + "k8s-openapi 0.24.0", Cargo.lock @@ -1573), while kube 0.88.1, kube-client and kube-core were rewritten to point at the old one (+ "k8s-openapi 0.21.1", @@ -4585, @@ -4608, @@ -4635), and a second [[package]] k8s-openapi 0.24.0 entry was added (@@ -4537). Two failure modes result:
     1. Previously, the validator's k8s-openapi = { version = "0.21", features = ["v1_29"] } unified features onto the same 0.21.x copy kube uses, supplying its mandatory v1_* version feature. After this bump, the 0.21.1 copy retained by kube gets no v1_* feature from anywhere in the workspace, which trips k8s-openapi's guard compile_error!("At least one of the v1_* features must be enabled…") — i.e., the build fails outright.
     2. Even if a feature were enabled on the 0.21.1 copy, k8s-openapi 0.24 types (Pod, ObjectMeta, etc.) are distinct Rust types from their 0.21 counterparts; any validator code passing them into kube 0.88 APIs (Api<T>, Metadata<Ty = ObjectMeta>, Resource bounds) fails to compile with trait-resolution errors.
   • How: Upgrade kube to the release line that depends on k8s-openapi 0.24 (per the upstream kube-rs/k8s-openapi version-correspondence table this is the kube 0.95/0.96 line — verify the exact pair with cargo tree -p kube before pinning), then regenerate the lockfile and confirm a single k8s-openapi copy:

     # crates/basilica-validator/Cargo.toml
     - kube = { version = "0.88", features = ["rustls-tls"] }
     - k8s-openapi = { version = "0.24", features = ["v1_29"] }
     + kube = { version = "0.96", features = ["rustls-tls"] }  # must be the release paired with k8s-openapi 0.24 — verify against upstream correspondence table
     + k8s-openapi = { version = "0.24", features = ["v1_29"] }

     Validate with cargo tree -d | grep k8s-openapi (must show zero duplicates) and cargo check -p basilica-validator, fixing any kube API breakage from the multi-minor jump (0.88 → 0.9x touches runtime module location, client builder, and deprecated Api helpers). Alternatively, close this PR and configure a Dependabot group (see Suggestions) so the pair always bumps together.

   Prompt for AI agents
   File: crates/basilica-validator/Cargo.toml (the kube/k8s-openapi lines near line 68).
   Problem: k8s-openapi was bumped to 0.24 while kube stays at 0.88, which depends on
   k8s-openapi 0.21.1 (see Cargo.lock: kube/kube-client/kube-core edges now say
   "k8s-openapi 0.21.1" while basilica-validator says "k8s-openapi 0.24.0"), so the
   build breaks (missing v1_* feature on the 0.21 copy and/or cross-version type mismatch).
   Task: bump `kube` to the release whose k8s-openapi dependency is exactly 0.24
   (check the kube-rs version-correspondence table / `cargo tree -p kube`), keep
   features = ["rustls-tls"], run `cargo update -p kube -p k8s-openapi`, then
   `cargo tree -d | grep k8s-openapi` must return nothing. Validate with
   `cargo check -p basilica-validator` and `cargo test -p basilica-validator`,
   repairing any kube API changes required by the version jump.
   

HIGH Severity Issues (Advised to Fix Before Merge)

None found beyond the CRITICAL pairing break above.

MEDIUM Severity Issues (Optional to Fix Before Merge)

1. Regenerate the lockfile with a minimal, precise update — the PR carries unrelated transitive bumps
   Maintainability & Coherency | MEDIUM | quick win
   • Why: Nine hunks change "windows-sys 0.59.0" to "windows-sys 0.61.2" (and one to 0.60.2, @@ -6196) for packages unrelated to k8s-openapi (dirs, errno, notify, rustix, tempfile, rustls-native-certs, etc.). A Kubernetes-client bump cannot justify re-resolving Windows FFI crates; this inflates review/audit surface in a financial service and obscures what the PR actually changes.
   • How: When applying the kube bump (Finding 1), regenerate with cargo update -p kube -p k8s-openapi --precise <version> and revert the windows-sys hunks, or recreate the PR after adding a Dependabot group so only the intended edges move.

LOW Severity Issues (Minor Improvements)

1. Consider aligning the v1_29 version feature with the target cluster version
   Maintainability & Coherency | LOW | quick win

   • Why: k8s-openapi = { version = "0.24", features = ["v1_29"] } remains valid (0.24 supports v1_28–v1_32), so this is not a bug; but 0.24 added v1_32 support, and if production clusters run ≥1.32, selecting v1_32 (or the oldest supported cluster version) keeps generated types matched to reality. Note 0.24 dropped K8s 1.26/1.27 APIs — confirm no cluster that old is still targeted.
   • How: Set the feature to the minimum Kubernetes version across managed clusters, e.g. features = ["v1_32"], and document the choice next to the dependency.

2. Nonstandard Conventional Commit type deps(deps) on the Dependabot commit
   Maintainability & Coherency | LOW | quick win

   • Why: The commit message deps(deps): bump k8s-openapi from 0.21.1 to 0.24.0 uses type deps, which is not a conventional type (feat, fix, chore, build, …). Expected format: chore(deps): bump k8s-openapi from 0.21.1 to 0.24.0. This is presumably configured in .github/dependabot.yml, so the fix belongs there, not in this PR's commit.
   • How: In dependabot.yml, set commit-message: { prefix: "chore", include: "scope" } (or accept deps as a documented repo convention).

Security Review

No executable code changes in this diff; the surface is supply-chain only. Swept and found:

• Dependency provenance: k8s-openapi 0.24.0 comes from the official crates.io registry with a recorded checksum (2c75b990…, @@ -4537); its transitive set (base64 0.22.1, chrono, serde, serde-value, serde_json) contains nothing unexpected.
• Duplicate major versions: Two k8s-openapi copies (0.21.1 + 0.24.0) would double the generated-API code under audit and is the canonical symptom of an unvetted kube/k8s-openapi skew — resolved by Finding 1.
• Unexplained transitive churn: windows-sys 0.61.2 enters the tree without any manifest change justifying it (Finding MEDIUM-1); benign in origin (Dependabot re-resolution) but exactly the kind of silent diff a lockfile review process should minimize.
• No surface for: injection, secret handling, authn/authz, crypto/randomness, deserialization of untrusted input, or resource-exhaustion changes — none touched by this diff.

Suggestions for Improvements

• Add a Dependabot group for the Kubernetes ecosystem (kube, kube-client, kube-core, kube-runtime, k8s-openapi) so the locked pair can never be bumped independently — this class of breakage recurs every k8s-openapi release otherwise.
• Add a comment above the two dependencies in Cargo.toml documenting the required pairing (# kube and k8s-openapi must be upgraded together; see k8s-openapi version-correspondence table).
• Consider a CI guard such as cargo tree -d or cargo-deny ([bans] multiple-versions = "deny" scoped to k8s-openapi) to fail fast on duplicate Kubernetes API crates.

Positive Observations

• The v1_29 feature remains a valid selection for 0.24, so no feature-flag breakage was introduced in the manifest itself.
• The lockfile correctly disambiguates the duplicated crate ("k8s-openapi 0.21.1" vs "k8s-openapi 0.24.0"), which is what makes the skew detectable at review time.
• The Dependabot description includes full release notes with the breaking-change callouts (dropped K8s 1.24–1.27 support), giving reviewers the compatibility information needed.

Recommendation and Next Steps

REQUEST_CHANGES — the bump upgrades k8s-openapi without its version-locked partner kube 0.88, leaving two incompatible k8s-openapi copies in the graph and a near-certain build failure; bump kube to the 0.24-paired release (or group the dependencies in Dependabot) and regenerate a minimal lockfile before merging.