This removes the DRAControlPlaneController feature gate, the fields controlled
by it (claim.spec.controller, claim.status.deallocationRequested,
claim.status.allocation.controller, class.spec.suitableNodes), the
PodSchedulingContext type, and all code related to the feature.
The feature gets removed because there is no path towards beta and GA and DRA
with "structured parameters" should be able to replace it.
This change updates the KDF "feature flag" to be per KMS provider
instead of global to the API server. This allows integration tests
that use distinct provider names to run in parallel.
Locally this change reduced the runtime of
test/integration/controlplane/transformation by 3.5 minutes.
Signed-off-by: Monis Khan <mok@microsoft.com>
add example of using CRI proxy
fix: Invalid function call
fix: Optimize getPodImagePullDuration
fix: Return error if the CRI Proxy is undefined
chore: add a document
Without this patch the error message for this example:
```
---
apiVersion: v1
kind: Pod
metadata:
name: test
spec:
containers:
- name: agent
image: debian:latest
tolerations:
- key: pool
operator: Exists
value: build
effect: NoSchedule
```
Looks like:
```
The Pod "test" is invalid: spec.tolerations[0].operator: Invalid value:
core.Toleration{Key:"pool", Operator:"Exists", Value:"build",
Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}: value must be
empty when `operator` is 'Exists'
```
To clarify that the `Value` field is wrong, we now directly point the
`field.Invalid` to it. Now the error message becomes a more clear and
concise one:
```
The Pod "test" is invalid: spec.tolerations[0].operator: Invalid value:
"build": value must be empty when `operator` is 'Exists'
```
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
This is not necessarily a problem, some code might use a timeout and expect it
to trigger. Therefore this should only be an info message, not a
warning. Long-term it might be useful to have an API where the caller decides
whether this gets logged.
The caller should use short messages and leave it to the user of those to
provide more context (no pun intended...). When logging, "canceling context" is
that context.
Before:
scheduler_perf.go:1431: FATAL ERROR: op 7: delete scheduled pods: client rate limiter Wait returned an error: rate: Wait(n=1) would exceed context deadline
contexthelper.go:69:
WARNING: the operation ran for the configured 2s
After:
scheduler_perf.go:1431: FATAL ERROR: op 7: delete scheduled pods: client rate limiter Wait returned an error: rate: Wait(n=1) would exceed context deadline
contexthelper.go:69:
INFO: canceling context: the operation ran for the configured 2s
