[sig-operator] test_id:3145 z-release upgrade flake: virt-api webhook context deadline exceeded on release-1.8
What happened
Flaky test detected: [sig-operator]Operator [rfe_id:2291][crit:high][vendor:[email protected]][level:component]should update kubevirt [release-blocker][test_id:3145]to target tested release from previous z release by patching KubeVirt CR
/kind flake /priority critical-urgent /sig compute
Additional context
The test fails during the z-release upgrade path on release-1.8 when attempting to create a VM using kubectl create -f vm-v1.yaml after the upgrade completes. The virt-api validating webhook times out:
Error from server (InternalError): error when creating "/tmp/ginkgo2595471531/vm-v1.yaml":
Internal error occurred: failed calling webhook "virtualmachine-validator.kubevirt.io":
failed to call webhook: Post "https://virt-api.kubevirt.svc:443/virtualmachines-validate?timeout=10s": context deadline exceededThe test has already verified "infrastructure is Ready" and confirmed all KV infra pods are running before this point, but virt-api is not serving webhook requests within the 10s timeout.
Key observations:
- The y-release upgrade variants of the same test both passed in this run
- The z-release "by updating virt-operator" variant also passed — only the "by patching KubeVirt CR" path failed
- This is on release-1.8, which predates the extra reconciliation attempts introduced on main — this is a different failure mode from #18396
Job: pull-kubevirt-e2e-k8s-1.35-sig-operator-1.8 on PR #18653 (IOThread pinning backport, unrelated to the failure)
Flake Action Plan
As the assignee, thoroughly review the issue and put the resulting report as comment into this issue.
Then decide on one of the following actions:
The flake is a bug
- Add label commenting
/triage accepted - Create a PR to fix the bug
- Reference this issue in the PR
- Keep this issue open until the testcase does not fail anymore
The flake is non-critical or an issue that is hard to fix
- Quarantine the test by creating a pull request assigning [QUARANTINE] tag to test name and Quarantine decorator to the test
- Reference this issue on the PR
There was an infrastructure issue
An infra issue is anything "below" the testcase
- Add label commenting
/triage infra-issue - Close the issue, adding a comment with details about the infrastructure issue.
After the flake has been fixed, document the learning from it inside the fix PR
Source: kubevirt/kubevirt