[bgly]

Summary

Makes the vrf meta plugin's cmdDel idempotent, as the CNI SPEC requires DEL
to be best-effort ("plugins should generally complete a DEL action without error
even if some resources are missing").

Problem

During concurrent netns teardown the VRF can be removed between findVRF and
LinkDel, so netlink.LinkDel(vrf) returns a bare ENODEV and cmdDel
propagated it. resetMaster had the same problem when the enslaved interface
was already gone (and dropped the underlying error by not wrapping it).

When vrf is used in a conflist (e.g. macvlan + vrf, as Multus generates),
a plugin error aborts the remaining reverse-order DELs in the runtime (libcni
DelNetworkList), so the chained macvlan DEL never runs. The orphaned
interface pins its netns via its dev_net reference and the namespace leaks; at
scale this exhausts the kernel namespace limit and new pods fail with
failed to create network namespace: resource temporarily unavailable.

cmdDel already handles the findVRF-not-found case and NSPathNotExistErr,
but not LinkDel/resetMaster. Note LinkDel returns a bare errno
(syscall.ENODEV), not netlink.LinkNotFoundError, so the type-assertion
guard used for findVRF does not catch it.

Changes

• cmdDel: treat LinkDel(vrf) not-found as success; route the existing
  findVRF guard through a shared helper.
• resetMaster: treat LinkByName not-found as success; wrap real errors with
  %w.
• New linkNotFound() helper matching netlink.LinkNotFoundError and
  errors.Is(ENODEV/ENOENT).
• Regression test: DEL succeeds when the enslaved interface is removed
  out-of-band.

Behaviour change

Only on the DEL error path: an already-removed VRF/interface now yields success
instead of an error. The happy path is unchanged. This mirrors the existing
NSPathNotExistErr handling.

Testing

go build / go vet / test-binary compile clean; added a unit test covering
resetMaster/findVRF idempotency. The LinkDel-ENODEV path is inherently a
race (VRF removed mid-cmdDel); it was validated out-of-tree by driving a
macvlan + vrf conflist through libcni with the race window forced
deterministically: 8/8 leaked without this change, 0/8 with it.

[bgly]

@squeed Can you possibly review or someone? This is live in production that we reproduced / fixing with a shim.

[bgly]

We do hit this in production. Can we get some level of review?

[mlguerrero12]

For consistency with other plugins, let’s keep the existing treatment of ENODEV. A subsequent DEL should succeed once lookup finds the device missing.

findVRF() already handles a missing VRF. The persistent failure is in resetMaster(): when the member interface is gone but the VRF remains, every retry fails at the same lookup. Handling netlink.LinkNotFoundError there is sufficient to fix that case.

For VRF deletion, you can leave it as it is or use the existing ip.DelLinkByName() helper and tolerate ip.ErrLinkNotFound.