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>
Validate the per-node kubeconfig when a current certificate is
available and fall back to the bootstrap kubeconfig only when the
per-node config is no longer trusted.
Also rebuild the derived per-node rest.Config from the reloaded
bootstrap config so TLS settings are preserved and refreshed
consistently.
Signed-off-by: Peng Liu <pliu@redhat.com>
Listing all pods across all namespaces during bootstrap is expensive
in large clusters and unnecessary since the result is discarded.
Use the lightweight /version endpoint to validate connectivity instead.
Signed-off-by: Peng Liu <pliu@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>
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>
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.
This change adds toleration for such errors like:
```
failed to [query/update] the pod pod-name-here in out of cluster comm: pod "pod-name-here" not found
```
During CNI ADD. While this change is a trade off in terms of debugability for RBAC, it's potentially noisy in scaled clusters when it is working properly.
This code changes CNI's GC command argument. Previously it just
passes from parent CNI runtime, however, it may causes unexpected
resource deletion if one CNI plugin is used in both cluster
network and net-attach-def. This change generates valid attachments
from multus CNI cache and passed to delegate CNI plugin.
It was explained to me that informers are almost always are more efficient, and in most cases will work, but a live lookup is appropriate after a number of failures.
This happens only on the retry portion, so we're still getting the benefits of informers, but, on a retry situation, we don't get a cache miss.
Additionally, changes out use of cache get on this, since it already bails out before it on CNI DEL.
If Multus plugin gets a DEL request, but the API Server is down (e.g.
via 'crictl rmp'), the call takes so long, it actually never finishes.
This prevents CRI-O from deleting the Pods.
APIReadyCheckFunc is used only in api, hence it can be decapitalize
to make its scope only in this package. This fix changes its scope.
In addition, api.APIReadyCheckFunc seems to be redundant so the name
is changed. Change the comment to fit to golang style, too.
deleteDefaultGWResult() may create 'routes:null' in CNI cache file
and it causes nil pointer access at addDefaultGWCacheBytes().
This code change prevents deleteDefaultGWResult() to generate
'routes:null' in cache file.
interface name should not be limited to DNS-1123 label format.
instead validate interface name if provided in pod network annotation
in a similar manner as iproute2[1].
this will allow to request interface names such as: "uplink_p0"
[1]11740815bf/lib/utils.c (L832)
Signed-off-by: adrianc <adrianc@nvidia.com>
On the CNI request failure, multus-cni prints out cmdArgs. In all
cases, except for debug printing, this is done with %s and a special
printing function. However, the handleCNIRequest is an exception for
some reason. That leads to unintelligible error messages in case
of CNI request failures (severely abridged):
CmdAdd (shim): CNI request failed with status 400:
'&{ContainerID:<id> Netns:/var/run/netns/<uuid> IfName:eth0
Args:<args> Path: StdinData:[125 121 111 117 114 32 97 100 118
101 114 116 105 115 101 109 101 110 116 32 99 111 117 108 100
32 98 101 32 104 101 114 101 125 ... another 650 numbers ]}
ContainerID:"<id>" Netns:"/var/run/netns/<uuid>" IfName:"eth0"
Args:"<args>" Path:"" ERRORED: error configuring pod ...
printCmdArgs() should be used for this case as well to avoid huge
hardly readable logs.
At the same time, the content of cniCmdArgs is always appended to
the error twice as seen in the example above. The first time by the
HandleCNIRequest and another time by the handleCNIRequest. Same for
the HandleDelegateRequest path.
Just removing the prefixing from the lower level handlers while
keeping higher level ones. The 'ERRORED' part migrated to the higher
level handler functions to preserve the overall look of the error.
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
Because deletes should favor a successful path, the readiness check should be skipped for pod removals.
This can cause an issue where there's pods pending deletes and that might impact scheduling of a pod that may be necessary in order to set the readiness indicator.
Adds a new method to check for readiness indicator alone in order to immediately log a warning.
When user recreate whole cluster certs, multus thick plugin's
previous cert is no longer valid. In such case, we need to prevent
to use cert manager's old certs and restart it from bootstrap
kubeconfig. This fix reloads client config from bootstrap
kubeconfig if cert mgr's cert is failed to load pod.
