Repository navigation
test(e2e): pin Kubernetes to v1.33.12 to avoid KCM VAP type-checker panic - #2868
Conversation
github-actions
Bot
added
the
area/testing
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request updates the end-to-end testing environment by pinning the Kubernetes version to v1.33.12. This change prevents a known issue where the kube-controller-manager would crash during cluster installation, ensuring greater stability and reliability for the test suite. Highlights
New Features🧠 You can now enable Memory (public preview) to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on Gemini (@gemini-code-assist) comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
github-actions
Bot
added
the
size/XS
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe e2e cluster preparation script now explicitly pins Kubernetes version v1.33.12 in the ChangesE2E Cluster Setup
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request pins the Kubernetes version to v1.33.12 in hack/e2e-prepare-cluster.bats to prevent a kube-controller-manager crash-loop during installation caused by a nil-pointer panic in older Kubernetes versions. Feedback was provided regarding the PR/commit title scope, which should use a valid meta scope like hack or tests instead of e2e to comply with the repository style guide.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| fi | ||
|
|
||
| rm -f controlplane.yaml worker.yaml talosconfig kubeconfig | ||
| # Pin Kubernetes to v1.33.12 instead of talosctl's bundled default (v1.33.1). |
There was a problem hiding this comment.
According to the Repository Style Guide, the commit/PR title scope e2e is not in the list of valid scopes. Please use one of the valid meta scopes such as tests or hack (e.g., test(tests): ... or test(hack): ...).
References
- Valid scopes for commits/PRs are strictly defined. For meta-related changes, valid scopes are
api,hack,tests,ci,docs. (link)
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@hack/e2e-prepare-cluster.bats`:
- Around line 234-241: The talosctl invocation uses the possibly-unsupported
flag --kubernetes-version in the talosctl gen config call and references an
unverifiable cozystack#2863 issue; confirm the talosctl version used by CI and
either replace --kubernetes-version with the talosctl-supported flag (or
configuration key) for pinning Kubernetes in the talosctl gen config command, or
remove the flag and set the Kubernetes version through the supported mechanism
(e.g., config file or env var) used by talosctl; also update the comment that
mentions cozystack#2863 to point to a verifiable issue/PR or reword to describe
the observed KCM crash behavior with a reference to kubernetes/kubernetes#135155
and `#136958` instead of the unverified local issue.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: f2ac7fb6-5de7-4afd-9c37-778c08028e51
📒 Files selected for processing (1)
hack/e2e-prepare-cluster.bats
| # Pin Kubernetes to v1.33.12 instead of talosctl's bundled default (v1.33.1). | ||
| # v1.33.1 predates the fix for the kube-controller-manager VAP status | ||
| # type-checker nil-pointer panic on `additionalProperties: true` schemas | ||
| # (kubernetes/kubernetes#135155, backported to release-1.33 in #136958, | ||
| # first released in v1.33.10). On the older default, cozystack-api's | ||
| # aggregated Tenant schema crash-loops KCM during install. See cozystack#2863. | ||
| talosctl gen config --with-secrets secrets.yaml cozystack https://192.168.123.10:6443 \ | ||
| --kubernetes-version v1.33.12 \ |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify that talosctl supports the --kubernetes-version flag
# Check talosctl gen config help for the flag
talosctl gen config --help 2>&1 | grep -A2 "kubernetes-version" || echo "Flag not found in help"Repository: cozystack/cozystack
Length of output: 86
🌐 Web query:
Kubernetes v1.33.12 release notes ValidatingAdmissionPolicy fix
💡 Result:
Kubernetes v1.33.12, released on May 12, 2026, includes a fix for a bug in ValidatingAdmissionPolicy [1][2][3]. The release addresses a nil pointer exception that occurred when an object schema contained additionalProperties: true, which could cause the kube-controller-manager to crash [4][1]. This fix was implemented via pull request #136958, which cherry-picked the resolution for the issue originally tracked in #136472 [4][1].
Citations:
- 1: https://github.com/kubernetes/kubernetes/blob/63b36867/CHANGELOG/CHANGELOG-1.33.md
- 2: https://groups.google.com/a/kubernetes.io/g/dev/c/_YHKlQqQQ3s
- 3: https://kubernetes.io/releases/1.33/
- 4: Automated cherry pick of #135155: Fix NPE in CEL schema wrappers of additionalProperties=true objects kubernetes/kubernetes#136958
🌐 Web query:
kubernetes/kubernetes issue 135155 VAP additionalProperties panic
💡 Result:
The Kubernetes issue labeled as 135155 (linked to 135145) pertains to a bug in ValidatingAdmissionPolicy (VAP) that caused the kube-controller-manager to crash with a nil pointer exception [1][2]. Specifically, this panic occurred when an object schema was defined with additionalProperties: true, but the associated schema was not explicitly set [1]. In such cases, the Common Expression Language (CEL) schema wrappers received a nil value for the schema, leading to a dereference error [1]. This issue was addressed in Kubernetes by pull request #135155, which was merged into the master branch on November 6, 2025, and included in the v1.35 release [1][3]. The fix involved updating the CEL schema wrappers to properly handle these nil values [1][4]. Backports of this fix were subsequently created for release branches v1.33 (PR #136958) and v1.34 (PR #136957) [5][6]. Users experiencing this crash should ensure their cluster is running a patched version of Kubernetes where this fix has been applied [3].
Citations:
- 1: Fix NPE in CEL schema wrappers of additionalProperties=true objects kubernetes/kubernetes#135155
- 2: Fix NPE in CEL schema wrappers of additionalProperties=true objects kubernetes/kubernetes#135155
- 3: https://groups.google.com/a/kubernetes.io/g/dev/c/z1uOCVCOsxA
- 4: kubernetes/kubernetes@de4e04b
- 5: Automated cherry pick of #135155: Fix NPE in CEL schema wrappers of additionalProperties=true objects kubernetes/kubernetes#136958
- 6: Automated cherry pick of #135155: Fix NPE in CEL schema wrappers of additionalProperties=true objects kubernetes/kubernetes#136957
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Searching talosctl gen config --help output for kubernetes/version flags =="
talosctl gen config --help 2>&1 | tee /tmp/talos-gen-config-help.txt >/dev/null
# show any lines mentioning kubernetes and/or version flags
rg -n --no-heading -i "kubernetes|version|k8s" /tmp/talos-gen-config-help.txt || true
echo
echo "== Exact match search for --kubernetes-version =="
rg -n --no-heading -F -- "--kubernetes-version" /tmp/talos-gen-config-help.txt || echo "not present"
echo
echo "== Exact match search for kubernetes-version without leading dashes =="
rg -n --no-heading -F -- "kubernetes-version" /tmp/talos-gen-config-help.txt || echo "not present"
echo
echo "== Try printing help and parsing only flag-like tokens mentioning kubernetes =="
python3 - <<'PY'
import re
text=open('/tmp/talos-gen-config-help.txt','r',encoding='utf-8',errors='ignore').read()
flags=set(re.findall(r'--[A-Za-z0-9][A-Za-z0-9_-]*', text))
k=[f for f in flags if 'kuber' in f.lower() or 'k8s' in f.lower() or 'version' in f.lower()]
print("\n".join(sorted(k)) if k else "(no kubernetes/version-related flags detected in help)")
PYRepository: cozystack/cozystack
Length of output: 204
🏁 Script executed:
#!/bin/bash
set -euo pipefail
HELP_FILE=/tmp/talos-gen-config-help.txt
echo "== Capturing talosctl gen config --help output =="
talosctl gen config --help >"$HELP_FILE" 2>&1 || true
echo "== Searching help output for kubernetes/version/k8s tokens =="
rg -n --no-heading -i "kubernetes|version|k8s" "$HELP_FILE" || true
echo
echo "== Exact match search for --kubernetes-version =="
rg -n --no-heading -F -- "--kubernetes-version" "$HELP_FILE" || echo "not present"
echo
echo "== Exact match search for kubernetes-version =="
rg -n --no-heading -F -- "kubernetes-version" "$HELP_FILE" || echo "not present"
echo
echo "== Detected flag-like tokens mentioning kubernetes/k8s/version =="
python3 - <<'PY'
import re
p="/tmp/talos-gen-config-help.txt"
text=open(p,'r',encoding='utf-8',errors='ignore').read()
flags=set(re.findall(r'--[A-Za-z0-9][A-Za-z0-9_-]*', text))
matches=sorted([f for f in flags if any(t in f.lower() for t in ("kuber","k8s","version"))])
print("\n".join(matches) if matches else "(no kubernetes/version-related flags detected in help)")
PYRepository: cozystack/cozystack
Length of output: 421
🏁 Script executed:
#!/bin/bash
set -euo pipefail
cat > /tmp/secrets.yaml <<'YAML'
{}
YAML
echo "== Running talosctl gen config with --kubernetes-version to see if flag is rejected =="
# Capture only the first error lines to avoid huge output
talosctl gen config --with-secrets /tmp/secrets.yaml cozystack https://127.0.0.1:6443 \
--kubernetes-version v1.33.12 1>/dev/null 2> /tmp/talos_gen_config_err.txt || true
echo "== talosctl stderr =="
head -n 40 /tmp/talos_gen_config_err.txt || trueRepository: cozystack/cozystack
Length of output: 220
🌐 Web query:
talosctl gen config --kubernetes-version flag
💡 Result:
The --kubernetes-version flag for the talosctl gen config command is used to specify the desired Kubernetes version to run in your Talos Linux cluster [1][2]. When you run talosctl gen config, this flag allows you to pin the generated machine configuration to a specific Kubernetes release [2]. If this flag is omitted, the command defaults to the Kubernetes version associated with your installed version of talosctl [2]. Example usage: talosctl gen config my-cluster https://10.0.0.1:6443 --kubernetes-version 1.30.5 [2] It is commonly used alongside other configuration flags—such as --talos-version (the version contract) and --with-secrets—to ensure reproducible machine configurations [3][4]. Ensuring these versions remain fixed is important for cluster stability and reproducibility, as changing them can lead to different default settings or field structures in your configuration [3][4].
Citations:
- 1: https://docs.siderolabs.com/talos/v1.7/reference/cli
- 2: https://oneuptime.com/blog/post/2026-03-03-generate-machine-configurations-talosctl-gen-config/view
- 3: https://siderolabs-fe86397c.mintlify.app/talos/v1.13/configure-your-talos-cluster/system-configuration/reproducible-machine-configuration
- 4: https://siderolabs-fe86397c.mintlify.app/talos/v1.12/configure-your-talos-cluster/system-configuration/reproducible-machine-configuration
🌐 Web query:
talosctl gen config default kubernetes version 1.33.1
💡 Result:
To generate configuration files for a Talos Linux cluster with a specific Kubernetes version, use the --kubernetes-version flag with the talosctl gen config command [1][2]. The command syntax is: talosctl gen config --kubernetes-version 1.33.1 For example: talosctl gen config my-cluster https://10.0.0.1:6443 --kubernetes-version 1.33.1 Key details: - The --kubernetes-version flag accepts both version formats (e.g., 1.33.1 or v1.33.1) [3]. - If the --kubernetes-version flag is omitted, talosctl will default to the Kubernetes version bundled with that specific version of talosctl [1]. - This command generates the required controlplane.yaml, worker.yaml, and talosconfig files [4][5].
Citations:
- 1: https://oneuptime.com/blog/post/2026-03-03-use-talosctl-gen-config-effectively/view
- 2: siderolabs/talos@fef99892d
- 3: siderolabs/talos@61cb2fb
- 4: https://docs.siderolabs.com/talos/v1.9/getting-started/getting-started
- 5: https://docs.siderolabs.com/talos/v1.11/reference/talosconfig
🌐 Web query:
CHANGELOG-1.33.md v1.33.10 136958
💡 Result:
The query refers to two distinct technical contexts involving the identifier 136958: 1. Kubernetes v1.33.10: In the context of the Kubernetes project, 136958 refers to pull request #136958, which was included in the v1.33.10 release (released March 19, 2026) [1][2][3]. This pull request, titled "Automated cherry pick of #135155: Fix NPE in CEL schema wrappers of additionalProperties=true objects," addresses a bug in the ValidatingAdmissionPolicy where an object schema containing additionalProperties:true could cause a nil pointer exception crash in the kube-controller-manager [2][3]. The CHANGELOG-1.33.md file for Kubernetes v1.33.10 documents this fix under the "Bug or Regression" section [4][2]. 2. Trainz Plus: The identifier 136958 also appears as a specific build number for the Trainz Plus TLR Phase 3 Release Candidate, released in June 2026 [5]. In this context, the changelog for build 136958 details various fixes for rendering issues related to rain, water, and TurfFX, as well as feature gate changes [5]. There is also a Nessus plugin (ID 136958) related to older Oracle Linux git security updates, which is unrelated to the above software versions [6][7].
Citations:
- 1: https://github.com/kubernetes/kubernetes/releases/tag/v1.33.10
- 2: https://groups.google.com/g/kubernetes-announce/c/RTU1xcOXzoo
- 3: Automated cherry pick of #135155: Fix NPE in CEL schema wrappers of additionalProperties=true objects kubernetes/kubernetes#136958
- 4: https://github.com/kubernetes/kubernetes/blob/63b36867/CHANGELOG/CHANGELOG-1.33.md
- 5: https://forums.auran.com/threads/trainz-plus-tlr-phase-3-release-candidate-windows-mac-136958-136957.184127/
- 6: https://www.tenable.com/plugins/nessus/136958/changelog/1.5
- 7: https://www.tenable.com/plugins/nessus/136958
🌐 Web query:
cozystack#2863 aggregated Tenant schema crash-loops kube-controller-manager
💡 Result:
There is no public record of an issue numbered #2863 in the Cozystack repository that specifically links an aggregated Tenant schema to a kube-controller-manager crash-loop. Current Cozystack development and issue tracking as of June 2026 shows that common causes for control plane and tenant-related crash-loops have been related to the following identified areas: 1. Computed Tenant Namespace Length: Issues with deeply nested tenants occasionally produced namespace names exceeding the 63-character Kubernetes DNS-1123 label limit [1]. This caused HelmReleases to fail, often leaving the Tenant CR in a stranded state [2]. This was addressed by adding synchronous validation to the Cozystack API to reject invalid names at the time of creation [2]. 2. Kamaji Control Plane Provider OOMKilled: The kamaji controller frequently encountered CrashLoopBackOff due to OOMKills [3][4]. This was caused by misconfigured resource limits (or lack thereof), which was resolved by standardizing resource requests and limits and correcting container naming in the Cluster API provider configuration [4]. 3. ResourceQuota Malformation: Older issues (e.g., #1636, #1746) identified that certain quotas, specifically for LoadBalancer services, could result in malformed ResourceQuota objects or failures during tenant deletion, which could lead to Helm hook timeouts [5][6]. If you are observing a crash-loop in kube-controller-manager, it is recommended to check the controller logs for specific panic signatures or OOM signals, and to ensure you are running the latest stable version of Cozystack (v1.4.0 or newer), which includes fixes for various stability and resource management issues [7].
Citations:
- 1: Tenant namespace validation gap: deep nesting can exceed the 63-character RFC 1123 label limit #2374
- 2: [platform] Validate computed tenant namespace length in cozystack-api #2376
- 3: https://github.com/cozystack/cozystack/releases/tag/v1.3.1
- 4: fix(cluster-api): fix kamaji OOM and set limits on unset providers #2708
- 5: Tenant with loadbalancer quota cannot be deleted #1746
- 6: Correctly handle resourceQuota creation for special types of quotas #1636
- 7: https://newreleases.io/project/github/cozystack/cozystack/release/v1.4.0
Address talosctl flag support and unverifiable cozystack issue reference in hack/e2e-prepare-cluster.bats (lines 234-241)
--kubernetes-version v1.33.12: external docs indicate the flag exists, buttalosctl gen config --helpoutput from this environment doesn’t list--kubernetes-version(or other kubernetes/version-related flags), so this may fail depending on the talosctl version used by CI—confirm the talosctl version used here and adjust to the supported flag if needed.- Kubernetes references: the
kubernetes/kubernetes#135155→#136958→ v1.33.x fix chain for the KCM nil-pointer panic with VAP +additionalProperties: truealigns with release/PR information. cozystack#2863: couldn’t find a public record matching the described “aggregated Tenant schema crash-loops KCM” behavior—update the link/wording to an issue that exists or document the exact failing behavior with a verifiable reference.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@hack/e2e-prepare-cluster.bats` around lines 234 - 241, The talosctl
invocation uses the possibly-unsupported flag --kubernetes-version in the
talosctl gen config call and references an unverifiable cozystack#2863 issue;
confirm the talosctl version used by CI and either replace --kubernetes-version
with the talosctl-supported flag (or configuration key) for pinning Kubernetes
in the talosctl gen config command, or remove the flag and set the Kubernetes
version through the supported mechanism (e.g., config file or env var) used by
talosctl; also update the comment that mentions cozystack#2863 to point to a
verifiable issue/PR or reword to describe the observed KCM crash behavior with a
reference to kubernetes/kubernetes#135155 and `#136958` instead of the unverified
local issue.
|
/retest |
…anic The e2e cluster bootstrap let `talosctl gen config` pick its bundled default Kubernetes version (v1.33.1 for Talos v1.13.0). That version predates the fix for the kube-controller-manager ValidatingAdmissionPolicy status type-checker nil-pointer panic on `additionalProperties: true` schemas (kubernetes/kubernetes#135155, backported to release-1.33 in #136958, first released in v1.33.10). cozystack-api's aggregated Tenant schema publishes `additionalProperties: true`, so on the older default KCM crash-loops cluster-wide during install and fails E2E. Pin the e2e management cluster to v1.33.12 (latest 1.33 patch) so it runs a Kubernetes that contains the fix. This complements the schema-side fix in #2867 and is independent of it. Refs: #2863 Assisted-By: Claude <[email protected]> Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> Signed-off-by: Myasnikov Daniil <[email protected]>
240d5bd to
43fd247
Compare
Aleksei Sviridkin (lexfrei)
left a comment
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
NOT LGTM — the change itself is correct and all factual claims verify, but the branch carries an empty CI-trigger commit that would land in main history under this repo's merge-commit-only policy.
Business context: e2e management-cluster bootstrap lets talosctl (1.10.4 in the e2e-sandbox image) pick its bundled default Kubernetes v1.33.1, which predates the fix for the KCM ValidatingAdmissionPolicy status type-checker nil-pointer panic; once a VAP matches an aggregated resource, KCM crash-loops cluster-wide during install (#2863). Pinning v1.33.12 unblocks e2e independently of the schema-side fix in #2867.
Blockers
B1: Drop the empty debug commit before merge
Issue: 43fd24734 ("ci: trigger debug e2e run for #2863 cilium/vpa investigation") is an empty commit (no file changes) pushed to trigger a CI run. This repo merges with merge commits only (squash/rebase disabled), so it will land in main history permanently.
Evidence: git show 43fd24734 --stat shows zero changed files.
Impact: permanent CI-trigger noise in main history.
Fix: once the debug run has served its purpose, drop it (git rebase -i / git reset --hard 96b9f5eac + force-push). The substantive commit 96b9f5eac is self-contained.
Non-blocking follow-ups
- The pin demonstrably works: the first pinned run passed Talos bootstrap and the whole install with no KCM panic in the logs. That run then failed in a different mode (
vpa-for-vpaHelmRelease timeout,PackageSource/cozystack.http-cache-applicationstuckInProgress). No mechanism links this to the kubelet patch bump, but independence isn't proven either — worth an explicit verdict (green rerun, or confirmation it reproduces onmainwith v1.33.1) before merging. - PR body wording: "v1.33.1 for Talos v1.13.0" is slightly misleading — the default belongs to the talosctl binary (1.10.4 from the e2e-sandbox Dockerfile), not to the Talos v1.13.0 node image. The in-code comment already states this correctly ("talosctl's bundled default").
Verified while reviewing: kubernetes/kubernetes#135155 and its release-1.33 backport kubernetes/kubernetes#136958 first shipped in v1.33.10 (backport merge commit is contained in the v1.33.10 tag and absent from v1.33.9); v1.33.12 is the latest 1.33 patch; ghcr.io/siderolabs/kubelet:v1.33.12 manifest exists; talosctl supports --kubernetes-version including the v-prefixed form (proven by the pinned run itself).
| # first released in v1.33.10). On the older default, cozystack-api's | ||
| # aggregated Tenant schema crash-loops KCM during install. See cozystack#2863. | ||
| talosctl gen config --with-secrets secrets.yaml cozystack https://192.168.123.10:6443 \ | ||
| --kubernetes-version v1.33.12 \ |
There was a problem hiding this comment.
Consider stating the unpin condition in this comment: drop the pin once the sandbox talosctl (packages/core/testing/images/e2e-sandbox/Dockerfile, TALOSCTL_VERSION) bundles a default >= v1.33.10, or once the schema-side fix (#2867) lands. Otherwise a future talosctl bump will silently keep the e2e management cluster on v1.33.12.
43fd247 to
96b9f5e
Compare
Aleksei Sviridkin (lexfrei)
left a comment
Aleksei Sviridkin (lexfrei)
left a comment
There was a problem hiding this comment.
LGTM — the empty CI-trigger commit is dropped; the branch now carries only the v1.33.12 pin. The fix is correct and matches the upstream timeline (kubernetes/kubernetes#135155, backported in #136958, first released in v1.33.10). Clears my earlier request.
2 participants
What this PR does
The e2e cluster bootstrap (
hack/e2e-prepare-cluster.bats) lettalosctl gen configpick its bundled default Kubernetes version — v1.33.1 for Talos v1.13.0.
v1.33.1 predates the fix for the kube-controller-manager
ValidatingAdmissionPolicystatus type-checker nil-pointer panic on
additionalProperties: trueschemas(kubernetes/kubernetes#135155,
backported to
release-1.33in#136958, first released in
v1.33.10). Because
cozystack-apipublishesadditionalProperties: trueon theaggregated Tenant schema, KCM crash-loops cluster-wide during install on the old
default and fails E2E (#2863).
This pins the e2e management cluster to v1.33.12 (latest 1.33 patch), which
contains the fix. It complements — and is independent of — the schema-side fix in
#2867; either alone avoids the panic.
Refs: #2863
Release note
Summary by CodeRabbit