converting plugin result to wrong config version results in regression
mikebrow opened this issue · comments
weaveworks/weave#3936
containerd/containerd#6921
@fuweid drafted a prototype fix:
fuweid/containerd@8c5607c
Interesting -- is this because Weave isn't following the spec (and not including cniVersion)? I never even thought that could be an issue.
Nevertheless, if we handled it in libcni beforehand, we should handle it now. The fix seems reasonable. @fuweid, want to file a PR against libcni?
nod.. puts us in a bind will need both cni lib and weave to fix.. weave fix so we can work fine from containerd 1.6.0-1.6.4 and here in cni so 1.6.5 can work with the version of weave that does not reply with config version in the result..
@mikebrow Shouldn't this work around Weave without them needing to fix their buggy behavior?
oh nevermind, I just parsed what you said. I'll see if I can bug anyone at weave.
yes it will.. and we'll put it in our r.next service stream right away after test and cni release tag and contained/go-cni brings in the new cni and containerd/containerd brings in the new go-cni and cherry pick to service for 1.6.5 ...
Sigh :-)
@mrunalp heads up another spin on cni lib coming to resolve weave issue with containerd and cri-o cheers..
Doesn't weaveworks/weave#3939 solve this issue?
@fuweid we talked about this at the CNI meeting -- can the behavior be to back-fill the result version to the config iff the result doesn't have a version specified?
This is valid. But fuweid/containerd@8c5607c is not quite right because it always copies from the config. While it's helpful to have libcni do this, it encourages plugins to be lazy and not conform to the spec's requirement of setting the Result CNIVersion correctly. Not everything using CNI uses libcni, thus not everything would benefit from this libcni fixup, thus plugins still need to Do The Right Thing.
can the behavior be to back-fill the result version to the config iff the result doesn't have a version specified?
Yes.
While it's helpful to have libcni do this, it encourages plugins to be lazy and not conform to the spec's requirement of setting the Result CNIVersion correctly.
The spec said that the cniVersion of result is the same version supplied on input https://github.com/containernetworking/cni/blob/main/SPEC.md#L480.
Based on that, I applied to request version to override the result, just in case that the plugin returns the wrong version.
Maybe out of topic. Is it possible to remove the version in result? The request always said what version it wants...
FTR, weave doesn't set the cni version in replies because it bundled an old version of cni. See weaveworks/weave#3936 (comment) for a more detailed explanation.
FWICT you're now trying to revert 76bf3de and treat the behaviour differently?