KubeVirt v1.8.2 publishes VMI status checksum fields (uint32 in Go) as
format: int32 in its generated CRD schema. k8s 1.36 enables strict
numeric format validation in CRDs via
https://github.com/kubernetes/kubernetes/pull/136582, which now rejects
the legacy schema and causes virt-handler to enter an infinite VMI
status update re-enqueue loop. Live migrations never complete and the
descheduler e2e TestLiveMigrationInBackground times out.
The schema fix landed upstream in
https://github.com/kubevirt/kubevirt/pull/17469 (merged to main on
2026-04-18, included in v1.9.0-alpha.0 tagged 2026-05-11) but was not
backported to release-1.8, so no v1.8.x release contains it. Bump the
default KUBEVIRT_VERSION to v1.9.0-alpha.0 so the e2e suite consumes a
release whose generated CRDs are compatible with k8s 1.36's stricter
validator.
Tracked in https://github.com/kubevirt/kubevirt/issues/17858.
Reverts b767b9c0f. The helper was added to work around what looked like
the virt-handler containerdisk-socket race on k8s 1.36, but the actual
root cause is unrelated: k8s 1.36's stricter CRD numeric format
validation (kubernetes/kubernetes#136582) rejects VMI status updates
with the pre-fix uint32 Checksum schema. See
https://github.com/kubevirt/kubevirt/issues/17858 for the upstream
context and kubevirt/kubevirt#17469 for the upstream fix (merged to
main, included in v1.9.0-alpha.0, not in v1.8.x).
The follow-up commit bumps KUBEVIRT_VERSION so the test consumes a
KubeVirt release that contains the fix, which removes the need for any
test-side retry.
Adds ensureVMIsLiveMigratable in TestLiveMigrationInBackground. After
the existing wait for virt-launcher pods to reach Running, poll each
VMI for the LiveMigratable=True condition. If a VMI fails to become
migratable within 120s, delete and recreate it (up to 3 attempts).
This works around an upstream KubeVirt race where virt-handler computes
the containerdisk checksum before the disk socket is ready, fails, and
never retries. The recreated VMI lands on a node that has already
cached the containerdisk image, so the socket comes up before
virt-handler's first attempt.
The race surfaces consistently with the kind v1.36.1 node image,
causing TestLiveMigrationInBackground to fail with "Expected at least
3 finished live migrations, got less: 0".
- Update kubevirt.io/api from v1.3.0 to v1.8.2
- Update kubevirt.io/client-go from v1.3.0 to v1.8.2
- Update kubevirt.io/containerized-data-importer-api from v1.57.0-alpha1 to v1.64.0
- Migrate e2e test from deprecated generated clientset path
(kubevirt.io/client-go/generated/kubevirt/clientset/versioned)
to new kubevirt.io/client-go/kubevirt client package
- Update vendor and dependencies for Kubernetes 1.36 compatibility
this commit introduces a new customization on the existing PodsWithPVC
protection. this new customization allow users to make pods that refer
to a given storage class unevictable.
for example, to protect pods referring to `storage-class-0` and
`storage-class-1` this configuration can be used:
```yaml
apiVersion: "descheduler/v1alpha2"
kind: "DeschedulerPolicy"
profiles:
- name: ProfileName
pluginConfig:
- name: "DefaultEvictor"
args:
podProtections:
extraEnabled:
- PodsWithPVC
config:
PodsWithPVC:
protectedStorageClasses:
- name: storage-class-0
- name: storage-class-1
```
changes introduced by this pr:
1. the descheduler starts to observe persistent volume claims.
1. a new api field was introduced to allow per pod protection config.
1. rbac had to be adjusted (+persistentvolumeclaims).
When the feature is enabled each pod with descheduler.alpha.kubernetes.io/request-evict-only
annotation will have the eviction API error examined for a specific
error code/reason and message. If matched eviction of such a pod will be interpreted
as initiation of an eviction in background.
* add ignoreNonPDBPods option
* take2
* add test
* poddisruptionbudgets are now used by defaultevictor plugin
* add poddisruptionbudgets to rbac
* review comments
* don't use GetPodPodDisruptionBudgets
* review comment, don't hide error
At the time of making this commit, the package `github.com/ghodss/yaml`
is no longer actively maintained.
`sigs.k8s.io/yaml` is a permanent fork of `ghodss/yaml` and is actively
maintained by Kubernetes SIG.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
