api,adaptation,generate: allow adjusting linux net devices

[klihub]

This PR adds NRI support for injecting 'linux net devices' a.k.a host side network interfaces into containers, building upon all the work @aojea did to make this possible.

Notes:
To test this in practice, one needs

• runc or crun with support for LinuxNetDevices in the OCI Spec,
  • I tested against runc v1.4.0-rc.1-146-g59a5ff14
• a patched runtime,
  • I tested with this patched containerd
• some way to inject linux net devices into containers,
  • I tested with the updated device-injector plugin from this PR
• and some test workload
  • I tested with a few host side VLANs and a test pod annotated for the device injector plugin

apiVersion: v1
kind: Pod
metadata:
  name: net-dev-test
  annotations:
    network-devices.noderesource.dev/container.c0: |
      - hostIf: ens2.100
        Name: netdev0
    network-devices.noderesource.dev/container.c1: |
      - hostIf: ens2.101
        Name: netdev1
spec:
  containers:
  - name: c0
    image: busybox:latest
    command:
      - sh
      - -c
      - sleep 3600
    resources:
      requests:
        cpu: 100m
        memory: 100M
      limits:
        cpu: 100m
        memory: 100M
    imagePullPolicy: IfNotPresent
  - name: c1
    image: busybox:latest
    command:
      - sh
      - -c
      - sleep 3600
    resources:
      requests:
        cpu: 1
        memory: 100M
      limits:
        cpu: 1
        memory: 100M
    imagePullPolicy: IfNotPresent
  terminationGracePeriodSeconds: 1

[aojea]

❤️

[klihub]

/cc @aojea @tao12345666333 Here is the draft PR proposal #180 was asking for.

[aojea]

This is fantastic @klihub , can we undraft it for final review

[klihub]

This is fantastic @klihub , can we undraft it for final review

We can try to do that to get it reviewed. @mikebrow WDYT?

But I think we won't be able to get this merged before the necessary new bits in runtime-spec gets behind a tag. Both CRI-O and containerd main/HEAD is at runtime-spec@v1.2.1 and I think we usually tend to stick to a tagged version in both even in main.

[aojea]

ok, that is fair

[aojea]

Fixes: #180

[aojea]

Containerd containerd/containerd#12295 is already testing runc 1.4.0-rc.2
CRIO uses crun that already has the feature https://github.com/containers/crun/releases/tag/1.22
OCI spec is close to release the definitive 1.3.0 opencontainers/runtime-spec#1295

[mikebrow]

Thx for the update @aojea

[klihub]

Containerd containerd/containerd#12295 is already testing runc 1.4.0-rc.2 CRIO uses crun that already has the feature https://github.com/containers/crun/releases/tag/1.22 OCI spec is close to release the definitive 1.3.0 opencontainers/runtime-spec#1295

@aojea @mikebrow But I think we'd still need a tagged version of opencontainers/runtime-spec we could point ourselves at.

[aojea]

@klihub yeah, I was using the comment as a breadcrumb , so next time I check I can track teh history, otherwise I forget

I was not trying to push for merging before that, sorry for the confusion

[klihub]

@klihub yeah, I was using the comment as a breadcrumb , so next time I check I can track teh history, otherwise I forget

I was not trying to push for merging before that, sorry for the confusion

@aojea No prob / no offense taken. I just asked to make sure I understand correctly where we are and whether we can try to move this forward yet.

[aojea]

informational update , ETA for 1.3.0 spec is 2025/11/04 opencontainers/runc#4875 (comment) , runc will follow

[klihub]

@aojea @mikebrow With opencontainers/runtime-spec v1.3.0 now tagged and released, unfortunately opencontainer/runtime-tools is now badly out of sync with runtime-spec.

runtime-spec@v1.3.0 brings a flips the linux PID limit setting the from int64 to *int64. While this allows to set an 'unlimited' limit using nil, it is a backward incompatible change and it essentially makes it impossible to import runtime-spec@v1.3.0 and runtimes-tools@current HEAD to the same golang code base.

I filed a PR for fixing this but I'm not sure what are the chances of getting that merged soon

[chrishenzie]

What are the keys, and why is a map chosen vs. repeated?

[aojea]

Because network interface names are unique, so there is no need to validate or fail at runtime, the keys are the interface name

[aojea]

it seems the dependency problem got unblocked

[chrishenzie]

nit: This is unrelated since I see this is an established pattern, but I'm not following why we would conditionally write info logs. I would think we would always info log, and then conditionally decide whether or not to additionally dump verbose output above

[klihub]

True. It is a bit strange not to log that info in verbose mode. We can fix all instances of that wrong pattern in a separate PR.

[klihub]

@chrishenzie #246

[mikebrow]

LGTM

[aojea]

yay

👏