`Remove` suppresses errors unnecessarily

[helsaawy]

(*libcni).Remove ignores not found errors, which suppresses valid errors from plugins that are cannot find the resource required to properly delete an interface.

A blanket ignore prevents the runtime from identifying and issue, and can cause future errors if the runtime tries to re-use the same interface name.

[mikebrow]

@MikeZappa87 is this something we could handle (or unhandle as it may be where version of plugin > some_version) either with check() or from plugin version information we may scrape from setup?

[MikeZappa87]

(*libcni).Remove ignores not found errors, which suppresses valid errors from plugins that are cannot find the resource required to properly delete an interface.

A blanket ignore prevents the runtime from identifying and issue, and can cause future errors if the runtime tries to re-use the same interface name.

In the case you mentioned reusing the same interface, isn’t the network namespace deleted and recreated? I am curious about the motivation for this conditional however it’s most likely safe to remove or handle very specific cases. Have you seen cases on the Windows side where this has caused an issue?

[helsaawy]

Have you seen cases on the Windows side where this has caused an issue?

We see a bug where the CNI cannot find the namespace, and therefore does not delete the network and interfaces specified (we are working on fixing that bug). However, containerd does not see the error, so we do not catch it until another pod is created with the same desired IP address, which then fails.

I do not have context as to why the strings.Contains(err.Error(), "not found") check was added, unfortunately.