name property of DP_MACVTAP_CONF can't exceed 10 characters

[tstirmllnl]

What happened:
The name property of DP_MACVTAP_CONF appears to have a character limit of 10 characters. I'm not sure if this due to it or the annotation that has to be set on the NetworkAttachmentDefinition.

What you expected to happen:
I didn't expect this character limit.

How to reproduce it (as minimally and precisely as possible):

1. Create macvtap device plugin configuration.
   NOTE: If you make the name field dataplanea and update NetworkAttachmentDefinition to be k8s.v1.cni.cncf.io/resourceName: macvtap.network.kubevirt.io/dataplanea it will work.

kind: ConfigMap
apiVersion: v1
metadata:
  name: macvtap-deviceplugin-config
data:
  DP_MACVTAP_CONF: |
    [
      {
        "name" : "dataplaneab",
        "lowerDevice" : "isol",
        "mode": "bridge",
        "capacity" : 50
      },
    ]

2. Deploy macvtap DaemonSet using: https://github.com/kubevirt/macvtap-cni/blob/main/manifests/macvtap.yaml
3. Deploy NetworkAttachmentDefinition

kind: NetworkAttachmentDefinition
apiVersion: k8s.cni.cncf.io/v1
metadata:
  name: isolated-net
  annotations:
    k8s.v1.cni.cncf.io/resourceName: macvtap.network.kubevirt.io/dataplaneab
spec:
  config: '{
      "cniVersion": "0.3.1",
      "name": "isolated-net",
      "type": "macvtap",
      "ipam": {
              "type": "host-local",
              "subnet": "172.31.0.0/20",
              "rangeStart": "172.31.12.1",
              "rangeEnd": "172.31.15.254",
              "routes": [
                { "dst": "0.0.0.0/0" }
              ],
              "gateway": "172.31.0.1"
            }
    }'

5. Deploy VM

apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
metadata:
  name: vmi-test
spec:
  domain:
    resources:
      requests:
        memory: 64M
    devices:
      disks:
      - name: containerdisk
        disk:
          bus: virtio
      - name: cloudinitdisk
        disk:
          bus: virtio
      interfaces:
        - name: isolated-network
          macvtap: {}
  networks:
    - name: isolated-network
      multus:
        networkName: isolated-net
  volumes:
    - name: containerdisk
      containerDisk:
        image: kubevirt/cirros-container-disk-demo:latest
    - name: cloudinitdisk
      cloudInitNoCloud:
        userData: |
            #!/bin/sh

            echo 'printed from cloud-init userdata'

kubectl describe prints out

Status:           Failed
Reason:           UnexpectedAdmissionError
Message:          Pod Allocate failed due to rpc error: code = Unknown desc = numerical result out of range, which is unexpected

Looking at the node where its scheduled it looks like the macvtap wasn't allocated.

Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                                  Requests    Limits
  --------                                  --------    ------
  cpu                                       702m (1%)   770m (1%)
  memory                                    815Mi (0%)  320Mi (0%)
  ephemeral-storage                         0 (0%)      0 (0%)
  hugepages-1Gi                             0 (0%)      0 (0%)
  hugepages-2Mi                             0 (0%)      0 (0%)
  devices.kubevirt.io/kvm                   0           0
  macvtap.network.kubevirt.io/dataplane      0           0
  macvtap.network.kubevirt.io/dataplanea     0           0
  macvtap.network.kubevirt.io/dataplaneab    0           0

NOTE: It also looks like it leaves macvtap.network.kubevirt.io/ resources from previous runs. How does one remove these?

Additional context:
Add any other context about the problem here.

Environment:

• KubeVirt version (use virtctl version): 1.1.0
• Kubernetes version (use kubectl version): 1.23.9
• VM or VMI specifications: N/A
• Cloud provider or hardware configuration: Baremetal
• OS (e.g. from /etc/os-release): CentOS 7
• Kernel (e.g. uname -a): 3.10.0-1160.11.1.el7.x86_64
• Other Tools: Multus Thick client(4.0.2)

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[maiqueb]

/remove-lifecycle stale

Hi, thanks for opening this issue. Sorry it took so long to get me to look at it.

I'll investigate the length limitation of the resource name. I'm inclined to say it is the name of the resource in the annotation that indirectly has this limitation, but right now I'm not sure.

It also looks like it leaves macvtap.network.kubevirt.io/ resources from previous runs. How does one remove these?

IIRC (been too long since I looked at this project ...) we never implemented support for this. I do agree that it is a known bug.

Would you mind opening a new one ?

[tstirmllnl]

@maiqueb No worries. New issue created about macvtap.network.kubevirt.io/ not getting cleared between runs has been created here: #121

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[kubevirt-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten