in general, the rewritten e2e cpumanager test assume cgroup v2.
A limited set of these may be updated to work also with the
obsolete and declining cgroup v1, but these need to be reviewed
on test-by-test matter.
To fix test failures, we add a top level require for cgroup v2,
skipping otherwise. This will fix the red lanes while we review
the testcases and the deprecation plan of the other tests.
Signed-off-by: Francesco Romani <fromani@redhat.com>
This moves the enabled/disabled test into the common test/integration/dra which
simplifies the code a bit and amortizes the cost of starting the apiserver
because several different tests can use the same instance, running in parallel.
While at it, setting the status via SSA also gets tested.
If preparing for a pod failed because the driver was not registered, it failed
after already having added the pod and claim to the claim info cache. The
effect was that deletion of the pod was blocked until the driver got
installed. Other errors had a similar effect. Now as many errors as possible
are checked in a read-only loop before proceeding to changing the claim info
cache.
The error message that was surfaced for the problem was not very readable:
Failed to prepare dynamic resources: failed to get gRPC client for driver dra-1411.k8s.io: plugin name dra-1411.k8s.io not found in the list of registered DRA plugins
To address this, error messages and wrapping get updated according to these
guidelines:
// Most errors returned by the manager show up in the context of a pod.
// They try to adher to the following convention:
// - Don't include the pod.
// - Use terms that are familiar to users.
// - Don't include the namespace, it can be inferred from the context.
// - Avoid repeated "failed to ...: failed to ..." when wrapping errors.
// - Avoid wrapping when it does not provide relevant additional information to keep the user-visible error short.
* Move the autoscaling e2e tests to be ran in parallel to have coverage for concurrent hpa processing
* Move the autoscaling e2e tests to be ran in parallel to have coverage for concurrent hpa processing
* Update autoscaling_utils.go
This can happen when a test is run in a cluster where a required feature gate
is turned off. Letting the test continue then fails less clearly. For example,
a test for partitionable devices runs with ResourceSlices which don't have
the additional fields for partitionable devices.
As soon as we have more than one test using the scheduler, we need some
coordination between tests. This is handled by a singleton which starts the
scheduler for the first user and stops it after the last one is gone.
To avoid having to pass around an additional parameter, the context is used to
access the singleton under the hood.
* Fix test flakiness caused by shadowed error in reboot test and stale pods affecting eviction test
- Fixed a bug in `ExecCommandInContainerWithFullOutput` usage in `hybrid_network.go` where the `err` variable was shadowed, causing test failures to be silently ignored.
- Added cleanup logic in `eviction.go` to explicitly delete pods created by the reboot node test (e.g., `img-puller`, `reboot-host-test-windows`) before starting the eviction test.
- This improves reliability of the eviction test when the reboot test runs beforehand and leaves behind memory-consuming pods.
* Add cleanup containers in reboot node test
* Workaround for Calico HNS issue by avoiding eviction of undeletable pods
Add a workaround for a known Calico issue (https://github.com/projectcalico/calico/issues/6974) where pods on Windows nodes may become undeletable after a reboot. This causes the eviction manager to attempt evicting these pods but fail due to HNS namespace deletion errors.
The workaround avoids scheduling critical test pods on rebooted nodes to prevent interference.
TODO: Remove this workaround once the Calico issue is resolved.
* Fix the lint issue.
* Address comments
The PR https://github.com/kubernetes/kubernetes/pull/130274 rewrote the
cpumanager tests assuming there are always at least 4 online CPUs,
adding checks for the tests which require more.
We still have, and likely we will have for the time being, lanes
which run on machines with 2 online CPUs.
Thus, every test which either reserve cpus (--reserved-cpus) or run
pods with exclusive CPU allocation must declare the requisites
and skip if the machine don't provide them.
Signed-off-by: Francesco Romani <fromani@redhat.com>
This enables proper scheduling tests. Most of them are probably better done in
scheduler_perf where the same test then can also be used for benchmarking and
creating objects is a bit better supported (from YAML, for example), but some
special cases (in particular, anything involving error injection) are better
done here.
