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 was broken since 666a41c2ea when the label value became non-integer encoded
The chance of one controller revision hash label being int-parsable: 7/27 ^ 8 = 0.00002041 = ~0
The chance of both being int-parsable: 0.00002041^2 = ~0
Hash comparison locks in differences in content failing EqualRevision
even when the semantic content is normalized to be equal.
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.
The main reason for the change is to fix the detection of incomplete pools. On
contrast to the previous attempt to fix this, now additional work only gets
done when the current pool is not already known to be complete. In other words,
most of the time no additional work is needed.
When doing the additional checking, then some cases of "updated devices no
longer available for now" can be detected. This is not a full solution, but
because DRA drivers doing this will have problems with race conditions anyway,
this is not something that needs to be supported better. DRA drivers simply
shouldn't be doing this.
This adds back the test case from the original fix and a few more.
The cache and scheduler event handlers cannot be registered separately in the
informer, that leads to a race (scheduler might schedule based on event before
cache is updated). Chaining event handlers (cache first, then scheduler) avoids
this.
This also ensures that the cache is up-to-date before the scheduler
starts (HasSynced of the handler registration for the cache is checked).
Other changes:
- renamed package to avoid clash with other "cache" packages
- clarified nil handling
- feature gate check before instantiating the cache
- per-test logging
- utilruntime.HandleErrorWithLogger
- simpler cache.DeletedFinalStateUnknown
Signed-off-by: Sai Ramesh Vanka <svanka@redhat.com>
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>
