Closed klihub closed 3 months ago
/cc
This change would make https://github.com/containers/nri-plugins/pull/327 redundant. Is there a way to detect that we're working with a runtime / plugin that supports CDI devices natively?
This change would make containers/nri-plugins#327 redundant.
I rolled this PR actually with that CDI injecting NRI plugin in mind (I mentioned this in the initial review of that plugin PR). The idea was to test/see how we could do native CDI injection through NRI. And, if we're happy enough with the result to merge it, to make the implementation of actual CDI device injection in that plugin much easier.
There are both pros and cons with this approach. The pros are
The cons are maybe that it is a bit superficial, as currently the container mutation capabilities offered by NRI are a superset of what is needed for CDI injection.
Is there a way to detect that we're working with a runtime / plugin that supports CDI devices natively?
Currently no other means than checking RuntimeName
and RuntimeVersion
in the plugin configuration NRI message, then using explicit knowledge about which runtime/version support started appearing in.
Add support for native CDI injection through NRI. With this patch set in place, a plugin can now directly request injection of CDI devices by fully qualified CDI device names. This is considerably simpler than what is currently required from an NRI plugin to perform CDI injection: perform CDI device resolution, then injection to an (almost) empty OCI Spec, inspect the resulting OCI Spec and convert the differences to a set of low-level NRI adjustments for devices, mounts, env. vars. and OCI hooks to effectively do the same through the NRI protocol.
/cc @elezar