CNIDeviceInfoFile are not generated once upgraded to v4.0

[yingzhan-msft]

Hello Multus community,

I've been using Multus v3.7 and am now considering an upgrade to the latest release. I used the sample deployment from /multus-cni/deployments/multus-daemonset.yml and kept everything else unchanged. However, I encountered an issue where the CNIDeviceInfoFile was empty in the runtime config when the request was passed down to the delegate CNI. This resulted in the k8s.v1.cni.cncf.io/networks-status not having device-info in the pod annotation.

By reviewing the Multus logs, it appears that the CNIDeviceInfoFile capability was not set, even though I had configured it as true in the network attachment definition. I'm curious if there is a need to make adjustments in the network attachment definition for the current release, as I did not face this issue in v3.7. Any suggestions would be greatly appreciated.

Network Attachment Definition

apiVersion: k8s.cni.cncf.io/v1
  kind: NetworkAttachmentDefinition
  metadata:
    name: n6-dpdk
    namespace: kube-system
  spec:
    config: |-
      {
        "name": "n6-dpdk",
        "cniVersion": "0.3.0",
        "type": "akshci-iov",
        "iovnetworkname": "n6",
        "dpdk": true,
        "sriov": true,
        "capabilities": {
          "deviceID": true,
          "ips": true,
          "CNIDeviceInfoFile": true
        }
      }

Multus config

{
        "cniVersion": "0.3.1",
        "name": "multus-cni-network",
        "type": "multus",
        "capabilities": {"bandwidth":true,"portMappings":true},
        "logLevel": "debug",
        "logFile": "/var/log/multus/cni/cni.log",
        "cniConf": "/host/etc/cni/multus/net.d",
        "kubeconfig": "/etc/cni/net.d/multus.d/multus.kubeconfig",
        "delegates": [
                {"cniVersion":"0.3.1","name":"k8s-pod-network","plugins":[{"datastore_type":"kubernetes","ipam":{"type":"calico-ipam"},"kubernetes":{"kubeconfig":"/etc/cni/net.d/calico-kubeconfig"},"log_file_path":"/var/log/calico/cni/cni.log","log_level":"info","mtu":1450,"nodename":"nodepool-5cb467456-p26mg","policy":{"type":"k8s"},"type":"calico"},{"capabilities":{"portMappings":true},"snat":true,"type":"portmap"},{"capabilities":{"bandwidth":true},"type":"bandwidth"}]}
        ]
}

Multus logs

2024-01-31T17:26:49-08:00 [debug] confAdd: &{04226cd81dc36513ee2b5bc775aba162375290e74d526b4edf5e0d26dfce40ea /var/run/netns/cni-39986091-66f3-81e2-4e09-b399f59f5046 net2 [[IgnoreUnknown true] [K8S_POD_NAMESPACE default] [K8S_POD_NAME dpdk-port5-7c4fb7c5b9-w26sq] [K8S_POD_INFRA_CONTAINER_ID 04226cd81dc36513ee2b5bc775aba162375290e74d526b4edf5e0d26dfce40ea] [K8S_POD_UID fe846dd4-cf51-41d7-8089-392d373174de] [K8S_POD_NAMESPACE default] [K8S_POD_NAME dpdk-port5-7c4fb7c5b9-w26sq] [K8S_POD_INFRA_CONTAINER_ID 04226cd81dc36513ee2b5bc775aba162375290e74d526b4edf5e0d26dfce40ea] [K8S_POD_UID fe846dd4-cf51-41d7-8089-392d373174de] [IgnoreUnknown 1]] map[] }, {
  "name": "n6-dpdk",
  "cniVersion": "0.3.0",
  "type": "akshci-iov",
  "iovnetworkname": "n6",
  "dpdk": true,
  "sriov": true,
  "capabilities": {
    "deviceID": true,
    "ips": true,
    "CNIDeviceInfoFile": true
  }
}
2024-01-31T17:26:58-08:00 [verbose] Add: default:dpdk-port5-7c4fb7c5b9-w26sq:fe846dd4-cf51-41d7-8089-392d373174de:kube-system/n6-dpdk(n6-dpdk):net2 {"cniVersion":"0.3.0","interfaces":[{"name":"net2","mac":"00:1d:d8:6c:ba:db","sandbox":"/var/run/netns/cni-39986091-66f3-81e2-4e09-b399f59f5046"},{"name":"net2_VF","mac":"00:1d:d8:6c:ba:db","sandbox":"/var/run/netns/cni-39986091-66f3-81e2-4e09-b399f59f5046"}],"ips":[{"version":"4","address":"192.168.167.4/16"}],"dns":{}}
2024-01-31T17:26:58-08:00 [debug] getDelegateDeviceInfo(): No CapArgs - info=<nil> ok=false

[yingzhan-msft]

I found delegateRc.DeviceID was empty so CNIDeviceInfoFile was not generated. The issue was gone upon reverting the changes introduced in this commit #644.
I'm looking for guidance on adding DeviceID to delegateRc, or is this possibly a bug? Any assistance with this would be appreciated.

[dougbtv]

There are no changes to the net-attach-def with the upgrade to 4.0, so that shouldn't have to change.

However, I'm curious if you've discovered anything more about the CNIDeviceInfoFile?

[yingzhan-msft]

Hi @dougbtv, I haven't identified the root cause yet. As a workaround for this issue, I removed the non-empty condition check for delegateRc.DeviceID introduced in this commit https://github.com/k8snetworkplumbingwg/multus-cni/pull/644/files#diff-668d0a8a613e2738bc66879510daa1c26f605997ce7a393dc1c4da73c9125c34 and built my own Multus image. With this workaround, the CNIDeviceInfoFile was automatically generated and it fixed my issue.

[github-actions]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.