[release/1.7] Bump tags.cncf.io/container-device-interface to v0.7.2

[elezar]

This includes migrating from cdi.GetRegistry() to cdi.Configure() and using top-level cdi Refresh and InjectDevices functions as applicable.

This backports the changes from #10041 to support the v0.7.0 CDI spec version.

[k8s-ci-robot]

Hi @elezar. Thanks for your PR.

I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[thaJeztah]

Curious; was there anything in runtime-spec 1.2.0 that's required by CDI, or does the repo have dependabot enabled, therefore automatically updating dependencies to "latest"?

The problem with a replace rule is that they only apply locally, and not to any consumer of the containerd module (i.e., anyone updating the containerd module will still be forced to update the runtime-spec).

If CDI itself does not require any of the features added in v1.1.0 or v1.2.0 of the spec, the correct approach may be to lower the required version (similar to containerd/platforms#5, which was opened for this reason)

Go modules uses "Minimum Version Selection" (MVS); https://go.dev/ref/mod#minimal-version-selection. For libraries, this means that the go.mod should always contain the minimum version needed to satisfy the library's requirements; which could be an older version of the runtime-spec (e.g. 1.0.0) of that version has all the required features. Specifying a low version means that consumers of the module can decide what version to use, as long as it's SemVer compatible (go modules dictates that SemVer must be followed, so if the module requires (say) v1.0.0, then consumers are allowed to pick any v1.x.x version that they need).

In some cases, it may be needed to update minimum required version if a dependency contains a vulnerability in parts of the code that's used; but strictly only if the code that's used is affected (this may be a bit of a grey area).

Dependabot can be a bit of an issue in these situations, as it directly conflicts with MVS principles when used on a library module.

[elezar]

There shouldn't be anything that we require from the v1.2.0, so we could definitely decrease the dependency there. We do have dependabot enabled in the repo and as you point out, we could look at disabling it instead.

Note that we do use github.com/opencontainers/runtime-tools to make OCI spec modifications and this has its own spec dependency: `https://github.com/opencontainers/runtime-tools/blob/master/go.mod#L11

This has also already caused issues in cri-o/cri-o#7971 where the testing infrastructure (which uses crun) has not yet been updated to a crun version that supports a lower spec.

@klihub for your information.

[elezar]

I have created cncf-tags/container-device-interface#202 to decrease the dependency version.

[estesp]

Looks like this can be updated to v0.7.2 now to get the updated/lowered dependency

[elezar]

Looks like this can be updated to v0.7.2 now to get the updated/lowered dependency

Updated the PR. PTAL.