When adding new features to the "experimental" allocator we are not directly
breaking "normal" usage of DRA because that uses the "incubating"
allocator. But we still want to know about potential performance problems also
for those test cases. If there is one, we might not be able to implement an
experimental feature in a way that allows promoting it later.
This is achieved by running the benchmarks twice as sub-tests, with different
topic names. The topic names then can be used to select different thresholds,
using a new extension of the scheduler_pref JSON config format.
This reverts commit d17ed9be17.
The CI jobs append
kubeadmConfigPatches:
- |
kind: ClusterConfiguration
etcd:
local:
dataDir: /tmp/etcd
With that commit also adding kubeadmConfigPatches, all jobs break with
mapping key "kubeadmConfigPatches" already defined at line 14
We have to update jobs first, then add the change back.
The Kubelet's DRA manager was failing to report device health status in a pod's status for certain types of resource claims. The logic incorrectly assumed that the claim name used within the container's spec (`container.resources.claims[*].name`) was the same as the metadata name of the actual ResourceClaim object.
This assumption is false in two key scenarios:
1. When a claim is generated from a `ResourceClaimTemplate`, Kubernetes creates a `ResourceClaim` object with a randomized suffix in its name.
2. When a user defines a pre-existing claim in `pod.spec.resourceClaims`, they can provide a local name that differs from the actual `ResourceClaim` object's name.
In both cases, the code would fail to find the claim's information in its internal cache, resulting in the health status not being populated, as reported in issue #134482.
This fix corrects the logic by using `pod.Status.ResourceClaimStatuses` as the authoritative map to look up the actual, generated name of the `ResourceClaim` object. This ensures that both templated and renamed claims are resolved correctly before their health status is retrieved from the cache.
Additionally, this change introduces a new node e2e test that specifically covers templated and renamed claims to prevent future regressions.
This avoids the risk of having a slow test started towards the end of a run,
which then would cause the run to take longer. When started early they can run
in parallel to other tests. In serial runs it doesn't matter.
The implementation maps the Slow label to the new ginkgo.SpecPriority. The
default is 0. Tests with priority 1 run first.
Copy VolumeGroupSnapshot v1beta2 CRDs from the external-snapshotter and
disable v1beta1 API in them - we can't run the conversion webhook in e2e
tests easily.
Update e2e tests to use v1beta2.
There's no plan anymore to promote these tests. They would have to be rewritten
to satisfy conformance test requirements (for example, self-contained and easy
to review) which doesn't seem worthwhile.
class mapping
- Add a new interface "DeviceClassResolver" in the scheduler framework
- Add a global cache of mapping between the extended resource and the
device class
- Cache can be leveraged by the k8s api-server, controller-manager along with the scheduler
- This change helps in delegating the requests to the dynamicresource
plugin based on the mapping during the node update events and thus
avoiding an extra scheduling cycle
Signed-off-by: Sai Ramesh Vanka <svanka@redhat.com>
This reverts commit cff07e7551.
The commit caused several kubeadm jobs to fail while executing all conformance
tests (including slow ones) in parallel. Sometimes execution took longer and
ran into the overall timeout, sometimes there was:
[FAILED] Expected
<int>: 440
to be ==
<int>: 400
In [It] at: k8s.io/kubernetes/test/e2e/apimachinery/chunking.go:202
It looks like the tests are flaky and/or reveal a real bug when slow tests run
all in parallel at the same time.
This should work, but doesn't right now, so let's revert until that problem is fixed.
This avoids the risk of having a slow test started towards the end of a run,
which then would cause the run to take longer. When started early they can run
in parallel to other tests. In serial runs it doesn't matter.
The implementation maps the Slow label to the new ginkgo.SpecPriority. The
default is 0. Tests with priority 1 run first.
