update OCI runtime spec to 1.3.0

[aojea]

This brings the new OCI runtime spec version 1.3.0 that brings some interesting new features like linux network devices

Ref: https://github.com/opencontainers/runtime-spec/releases/tag/v1.3.0

[klihub]

@aojea @mikebrow @kad Unforteunately there is a cascading CF brought upon us by v1.3.0. It changes the golang type used for setting linux PID limit from int64 to *int64. While this allows one to set a explicit nil as a semantic 'unlimited' limit, it is a backwaard incompatible change and the golang level, so it prevents us from importing [email protected] and runtime-tools@HEAD to the same golang codebase. I file a PR for fixing it, but I'm not too optimisitic for getting that merged soon (just by looking at the number of unmerged PRs).

[aojea]

oh, thanks I was also trying to untangle this opencontainers/runtime-tools#796, let me hand over to you since you are much more familiar

[klihub]

oh, thanks I was also trying to untangle this opencontainers/runtime-tools#796, let me hand over to you since you are much more familiar

@aojea Yeah, I will try. Unfortunately this bites us in the arse on multiple fronts. The immediate breaking effects are relatively easy to fix, provided we can land something like the pending opencontainers/runtime-tools#795 merged.

But even if we do, we have a problem with our existing v010-adapter plugin, which tries to implement drop-in backward-compatibility for v0.1.0 NRI plugins. And it has (containerd 1.7.x) dependencies which have functions for setting the very same linux PID limit for which the type has changed, but of course with the original type. So that plugin has now become uncompilable.

TBH, I don't know who came up with the idea of changing PID limit in the OCI Spec this way (instead of using int64 0 or -1 as a special 'unlimited' placeholder), or who and why allowed that change to go in. But I have to say, that this is already right among the top 3 favorite changes in any golang package to hate with passion... it's a real PITA.

[aojea]

no worries, there is no rush, at least not in my side , and unfortunately this things happen ... so let's do one step at a time, at least is a good exercise to remember how important and impactful are the breaking changes on the APIs ;)

[klihub]

Closing in favor of #243.