Add NRI plugin for CDI device injection #327
Conversation
|
/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
force-pushed
the
add-cdi-device-injector
branch
2 times, most recently
from
2ac463d
to
0719394
Compare
|
@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:
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. |
|
|
||
| var allowedCDIDevices []string | ||
| for _, cdiDevice := range cdiDevices { | ||
| match, _ := filepath.Match(p.allowedCDIDevicePattern, cdiDevice) |
There was a problem hiding this comment.
I think it would be better to use path.Match() for globbing instead of filepath.Match().
Signed-off-by: Evan Lezar <[email protected]>
Signed-off-by: Evan Lezar <[email protected]>
This change adds an allowed-cdi-device-pattern command line option to the CDI device injector to allow CDI device names to be filtered. Signed-off-by: Evan Lezar <[email protected]>
elezar
force-pushed
the
add-cdi-device-injector
branch
from
0719394
to
2206edc
Compare
Signed-off-by: Evan Lezar <[email protected]>
Signed-off-by: Evan Lezar <[email protected]>
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:
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 containerd/nri#98