Add NRI plugin for CDI device injection
This PR adds a plugin for CDI injection.
The values of defined pod annotations are interpreted as a comma-separated list of CDI devices. The local CDI cache is read and the corresponding container adjusments are generated.
Some items to do:
- [ ] Make the CDI folders configurable
- [ ] Consider which of this code should be upstreamed into the CDI packages
In the longer-term, it should also be possible to restrict the injection of devices to containers in a particular namespace / based on properties of a namespace.
I have updated this to pull in the API changes from https://github.com/containerd/nri/pull/98
/cc @klihub
/cc @klihub
I can take a look at adding native CDI injection support to NRI based on this/an earlier very similar CDI injection sample plugin we had in the first versions of v0.2.0 NRI PR...
@elezar @kad @askervin I rolled a proof-of-concept/initial implementation of CDI device injection in NRI, directly supported by the protocol and supporting libraries. I also updated containerd 1.7 and main/2.0 and cri-o main to allow CDI injection through. The NRI bits also update the test/sample device-injector plugin (in the NRI repo itself) to allow injecting CDI devices by annotation. This is what I used for testing against all of the updated containerd and cri-o trees.
Here are the related working trees/branches:
- https://github.com/klihub/nri/tree/devel/native-cdi-injection
- https://github.com/klihub/containerd/tree/devel/release-1.7/nri-cdi-injection
- https://github.com/klihub/containerd/tree/devel/release-2.0/nri-cdi-injection
- https://github.com/klihub/cri-o/tree/devel/nri-cdi-injection
Based on this, it looks technically feasible, fairly straightforward, and not very intrusive to implement. Next we should decide if we want to push this or not. It has pros but maybe semantically it is a bit of an outlier compared to the rest of our features.
@elezar Is this still relevant for you ? Or should this be closed now as obsolete since we have DRA adminAccess ?
@elezar Is this still relevant for you ? Or should this be closed now as obsolete since we have DRA adminAccess ?
I think the may still be relevant for non-DRA use cases such as Device Plugins. Maybe @klueska kan weigh in on this.
Let's leave it open for now until we understand how well support for this will let us move away from the device plugin completely.