Kubernetes-specific CNI_ARGS always added

[DennisGlindhart]

The code constructing the CNI_ARGS value seems to be initialized with specific variables: K8S_POD_NAMESPACE, K8S_POD_NAME and K8S_POD_INFRA_CONTAINER_ID.

ocicni/pkg/ocicni/ocicni.go

Line 869 in 513ef78

{"K8S_POD_NAMESPACE", podNetwork.Namespace},

My understanding is that these are Kubernetes-specific, and not part of CNI specification.

At least one CNI-plugin (and probably others) checks for the presence of these variables in CNI_ARGS to decide whether being in K8S context or "generic" CNI.

For example code from Calico CNI Plugin: https://github.com/projectcalico/cni-plugin/blob/eb74819f8618478746606378fe3b64c76f54c909/internal/pkg/utils/utils.go#L435

My specific use-case is trying to use Calico as CNI-plugin via Podman which (to my understanding) uses this project (OCICNI) somewhere in the stack to call the CNI-plugin. That doesn't work for me because OCICNI adds the K8S_POD_NAMESPACE arg to CNI_ARGS so Calico behaves as it were inside K8S Cluster instead of as generic CNI.

So what I'm trying to understand is whether it is intended that the OCICNI project contains K8S specific things like the above K8S-specific arguments? Or is Podman not supposed to use this project as "generic" CNI-library?
The relationship between Podman, libpod, CRI-O and OCICNI is a bit confusing to me (and what parts are supposed to be K8S-specific).

TL;DR - Would it be possible to not have K8S_xxx args send to the CNI-plugin somehow?

[haircommander]

ocicni was originally designed just for cri-o, which was designed just for k8s. Then, podman came along, and reused a bunch of cri-o and ocicni code. This seems to remain from that initial fork, and has never been addressed.

I definitely think it'd be possible, but the implementation may need to be figured out. Maybe we could use the ...WithContext functions and the caller could use the context to say what to do

thoughts @mheon @mrunalp @mccv1r0

[mheon]

I wouldn't mind having a way to disable this on the Podman side, though we might want to consider doing it on a per-network basis - setting those variables for a Podman pod network sounds like it makes sense, but for individual containers, it doesn't, really.