github.com/container-orchestrated-devices/container-device-interface and
github.com/opencontainers/runtime-tools depend on some problematic packages in
code that isn't used by Kubernetes. Explicitly listing those dependencies
ensures that they do not get pulled in accidentally.
These instructions bring up a kind cluster with containerd 34d078e99, the
latest commit from the main branch. This version of containerd has
support for CDI.
The driver can be used manually against a cluster started with
local-up-cluster.sh and is also used for E2E testing. Because the tests proxy
connections from the nodes into the e2e.test binary and create/delete files via
the equivalent of "kubectl exec dd/rm", they can be run against arbitrary
clusters. Each test gets its own driver instance and resource class, therefore
they can run in parallel.
Directly after modifying a ResourceClaim in the apiserver, the locally cached
copy is outdated until the informer receives the update. If any operation looks
at the claim during that time frame, it will act based on stale
information. For example, it might try to allocate again. If that works because
of idempotency, then the following update operation fails with a conflict
error.
This is harmless, but leads to confusing log output. It can be avoided by
keeping a copy of the updated claim and using that instead of the one from the
informer cache.
These helper packages implement the parts of a dynamic resource allocation
driver that are generic and can be used by the in-tree test driver as well as
out-of-tree vendor drivers.
Functional options make it possible to treat some parameters as
optional (logger) and extend the API later on.
Dependencies need to be updated to use
github.com/container-orchestrated-devices/container-device-interface.
It's not decided yet whether we will implement Topology support
for DRA or not. Not having any toppology-related code
will help to avoid wrong impression that DRA is used as a hint
provider for the Topology Manager.
due to redesign where we changed from new endpoint to /apis. The expected error was not also changed.
Caught by e2e tests when feature enabled. Should have been caught by unit test first but it was implemented without root /apis. Unit test also fixed
The controller uses the exact same logic as the generic ephemeral inline volume
controller, just for inline ResourceClaimTemplate -> ResourceClaim.
In addition, it supports removal of pods from the ReservedFor field when those
pods are known to not need the claim anymore. At the moment, only this special
case is supported. Removal of arbitrary objects would imply granting full read
access to all types to determine whether a) an object is gone and b) if the
current incarnation is the one which is listed in ReservedFor. This may get
added later.
This is similar to the support code for generic ephemeral inline volumes.
Differences:
- to avoid stuttering, the functions are just resourceclaim.Name and
resourceclaim.IsForPod
- resourceclaim.Name returns the right name for both cases (template
and reference), which will simplify some code
Other helper functions check some simple status conditions.
This will be used for different individual packages. A separate repo
is better than reusing something like component-helpers because dependencies
will be different.
This is in response to review feedback. Checking for valid node names and the
set property catches programming mistakes in the components that have write
permission.
