api,adaptation,stub: version exchange and capability advertisement. #265
Conversation
klihub
force-pushed
the
devel/version-exchange-and-capabilities
branch
7 times, most recently
from
0d93f22 to
fa03208
Compare
samuelkarp
left a comment
samuelkarp
left a comment
There was a problem hiding this comment.
I'm not entirely sure I understand the value of having both version comparison and capabilities. They both effectively serve the same purpose of understanding compatibility between plugin and runtime, but operate in slightly different ways. I tend to think capabilities are generally a better option in that they're more descriptive of the required functionality and need less manual mapping over time, but I can see some debugging value in exposing version too.
Yes, I'd like to add one more thing for existing runtime versions: supported capability inference based on runtime NRI version. Then as long as a plugin declares required capabilities, we could perform a capability based compatibility check for both old and new runtime versions, either using inferred or reported capabilities. The PR now does a version check only if a plugin does not declare required capabilities. I added it so that similar cases than what @micahhausler ran into would be flagged as an error of (assumed) incompatibility by default. We can leave it out, and then if a plugin does not declare required capabilities, we don't do any compatibility check either... |
klihub
force-pushed
the
devel/version-exchange-and-capabilities
branch
8 times, most recently
from
1a28e8a to
8358b6a
Compare
Signed-off-by: Krisztian Litkey <[email protected]>
Exchange NRI versions in use during plugin registration. If we do not get an NRI version from the runtime (too old peer NRI) try to infer it using the runtime type and version. The NRI version in use is discovered using the golang runtime provided build info. For plugins hosted in the main NRI repo this does not produce any useful result (because NRI is subject to a replace directive in the plugins' go.mod). Therefore within the repo we fall back to using a git-describe generated version. Signed-off-by: Krisztian Litkey <[email protected]>
Add version exchange test and related test option to adaptation. Signed-off-by: Krisztian Litkey <[email protected]>
Introduce an NRI protocol capability enum, add a capability mask to the protocol and define values for existing NRI features that were not present in v0.2.0. If the runtime does not advertise capabilities, try to infer it on the stub side using the runtime name, version, and (inferred or reported) NRI version. Add options to advertise supported capabilities by the runtime and check them against any required capabilities on the plugin side. Signed-off-by: Krisztian Litkey <[email protected]>
Signed-off-by: Krisztian Litkey <[email protected]>
Add required NRI capabilities to device-injector, ulimit-adjuster and rdt sample plugins. Signed-off-by: Krisztian Litkey <[email protected]>
klihub
force-pushed
the
devel/version-exchange-and-capabilities
branch
from
8358b6a to
6164f48
Compare
|
@samuelkarp @mikebrow @chrishenzie @kad I reworked this, ditching support for direct version checks (which plugins can do on their own accord if they ever need to, using information provided by the stub), adding the necessary options for capability declaration and requirements, and adding verification of those against each other, if both are provided. Inferred capabilities based on the reported runtime version is used for existing containerd and CRI-O versions which do no advertise capabilities. I also added a few minimal test cases. I took off the draft status as I think this should be now ready for a real review round, if you guys have some extra cycles to spare. |
2 participants
This patch series
Updates:
@samuelkarp @mikebrow I reworked this, ditching version-based checks and implementing more complete support for capability-based checks. Also added capability requirements to plugins which need some specific features that correspond to a capability.