STATUS and GC are plugin-level commands with no pod context per the
CNI 1.1.0 spec. The thick plugin daemon incorrectly required
CNI_CONTAINERID, CNI_NETNS, and K8S_POD_NAME/K8S_POD_NAMESPACE for
these commands, causing failures when invoked by kubelet.
Signed-off-by: Jason Kary <jkary@redhat.com>
When a namespace uses a primary User-Defined Network (UDN) with a
device-plugin resource (e.g. SR-IOV), OVN-Kubernetes uses the last
device in the list for the primary interface while Multus assigns
earlier devices to cluster-default/secondary interfaces. The kubelet
and checkpoint paths build the list from map iteration, so order was
non-deterministic and the "last" device could differ between callers.
Sorting ensures both Multus and OVN-K8s see the same order so the
last device is consistently the one reserved for the primary UDN.
Signed-off-by: Yun Zhou <yunz@nvidia.com>
The trivy-action@0.29.0 was trying to install Trivy v0.57.1 which
no longer exists in the GitHub releases. This was causing all PR
builds to fail on the "Image thick plugin" job. Update to v0.35.0
which properly installs the latest Trivy version.
Assisted by Claude Sonnet 4.5
Signed-off-by: Benjamin Pickard <bpickard@redhat.com>
Fix thin auto-config generation to select 00-multus.conflist for
all CNI versions >= 1.0.0 (not only exact 1.0.0)
Signed-off-by: Tim Rozet <trozet@nvidia.com>
Changes-Include:
- Add STATUS handling for delegate requests and single‑plugin
- Invoke STATUS for conf/conflist delegates via libcni
- Preserve CNI error codes/messages through daemon API and shim
- Add tests for STATUS error propagation
Signed-off-by: Tim Rozet <trozet@nvidia.com>
Currently, the default CNI config dir is /etc/cni/multus/net.d [1].
However, pods do not mount this hostPath.
This issue only occurs when a delegate network-attachment-definition
has no spec, and it therefore needs to be loaded from disk[2].
For example, when deploying Istio-cni in multus mode,
the deployment creates an empty Istio-cni NAD in default namespace, while
the actual config is deployed on disk.
CmdAdd fails with the following error message:
GetNetworkDelegates: failed getting the delegate: GetCNIConfig:
err in GetCNIConfigFromFile: No networks found in /etc/cni/multus/net.d
[[1]](https://github.com/k8snetworkplumbingwg/multus-cni/blob/v4.2.0/pkg/types/conf.go#L38)
[[2]](https://github.com/k8snetworkplumbingwg/multus-cni/blob/v4.2.0/pkg/k8sclient/k8sclient.go#L506)
Signed-off-by: Nir Dothan <ndothan@redhat.com>
Removes the it `fails to execute confListDel given no 'plugins' key"` test.
This test no longer fails after libcni version 1.2.3.
It probably shouldn't failduring a DEL action as it is, we want the least error prone path.
The GC test now uses both cni.dev attachment formats.
Uses both attachment formats as per https://github.com/containernetworking/cni/issues/1101 for GC's cni.dev/valid-attachments & cni.dev/attachments
sometimes pods get deleted super fast (like jobs or CI) and they come back as not found.
instead of erroring, just return an empty CNI result so things don't blow up.
adds a sentinel errPodNotFound and skips the rest of CmdAdd when we hit it.
shouts to race conditions.
