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
This consumes the latest release of the network-attachment-definition-client
library which fixes a regression affecting CNI plugins that do not specify
interfaces in their CNI ADD result. This was fixed in [0].
[0] - https://github.com/k8snetworkplumbingwg/network-attachment-definition-client/pull/77
Signed-off-by: Miguel Duarte Barroso <mdbarroso@redhat.com>
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.
Otherwise, the latest changes to DRA (which is beta in K8s 1.32) are incompatible.
Additionally, this:
* Bumps kind version to 0.27.0
* Changes `loglevel` flag to `v` verbosity flag for `kind export logs`
* fixes lint in the Dockerfile.
* adds a couple notes in the docs.
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.
From the release notes:
> This release contains a fix related to the determination of the default interface, e.g. setting the default parameter to true in the network-status annotation based on the presence of a gateway in the CNI ADD success result ips.gateway and makes the determination of the default based on the first interface that has an associated value of gateway (using the interface index in the ips element in the CNI ADD success result).
> This provides flexibility especially in CRI-O which uses the first interface and IP addresses for the pod.IP in Kubernetes, therefore. Containerd functionality is unchanged in that it uses the value for the IP addresses specifically
> It's worth noting that CNI ADD success results which do not contain any interfaces will be discarded in this determination of the default, therefore it's recommended to set one with an associated gateway if aiming to have it be noted as the default.
See also:
https://github.com/k8snetworkplumbingwg/network-attachment-definition-client/releases/tag/v1.7.5https://github.com/k8snetworkplumbingwg/network-attachment-definition-client/pull/73
Previous version didn't account for accounts for the sandox interfaces when reporting the interfaces in the network-status annotation when calculating the default:true interface
This fixes the default:true for multiple interface returns from CNI for cluster default network, where all interfaces in that return were marked as default:true in the network-status
