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.
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.
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.
this feature gate was meant to be ephemeral, and only was used for guaranteeing a
cluster admin didn't accidentally relax PSA policies before the kubelet would deny a pod
was created if it didn't support user namespaces. As of kube 1.33, the supported apiserver version
skew of n-3 guarantees that all supported kubelets are of 1.30 or later, meaning they do this.
Now, we can unconditionally relax PSA policy if a pod is in a user namespace.
This PR reserves older policies default behavior by never relaxing
Signed-off-by: Peter Hunt <pehunt@redhat.com>
Add an e2e test verifying that pods requesting extended resources
can still be admitted and processed by DRA after the corresponding
device plugin is uninstalled. The test deploys a sample device plugin,
waits for its extended resource to appear on a node, uninstalls the
plugin, and then creates a pod requesting that resource. It confirms
that the pod starts successfully and that the DRA driver processes the
resource as expected.
