Error in specification regarding GC??

[kanpov]

CNI spec says extra JSON key in GC is cni.dev/attachments yet libcni uses cni.dev/valid-attachments? What is it then if the spec doesn't even correspond to the official runtime?

[kanpov]

I'm asking this because I'm developing a CNI runtime and this lack of clarity is a problem (runtime in question: https://github.com/FirecrackerSharp/CniDotNet/tree/main)

[squeed]

Oops! That is a very silly mistake indeed.

My plan is to change the spec to match libcni, as libni is probably more directly meaningful. In the unlikely event that there is spec-conformant code, I will set both keys. Make sense?

[kanpov]

Oops! That is a very silly mistake indeed.

My plan is to change the spec to match libcni, as libni is probably more directly meaningful. In the unlikely event that there is spec-conformant code, I will set both keys. Make sense?

Yes, probably, but I think the spec should keep cni.dev/attachments and not be changed, but only libcni is changed to actually adhere the spec. What do you think?

[bleggett]

My $0.02 is that

• cni.dev/valid-attachments is a better name anyway
• We don't have meaningful back compat concerns at this point for this feature

So tweaking the spec and throwing the back compat concern into libcni like #1103 does puts us into a better state.

[kanpov]

My $0.02 is that

• cni.dev/valid-attachments is a better name anyway
• We don't have meaningful back compat concerns at this point for this feature

So tweaking the spec and throwing the back compat concern into libcni like #1103 does puts us into a better state.

Sure, but there's no way this change doesn't require a version bump (that is, if CNI follows semver) to 1.2