Test failures with new multus 4.1.1 (thick/thin)

[oshoval]

What happened:
Instead deploying CNAO's multus, deploy multus 4.1.1 and run tests
one test always fail

macvtap-cni
/root/go/src/github.com/macvtap-cni/tests/e2e/macvtap_test.go:66
  macvtap resource creation
  /root/go/src/github.com/macvtap-cni/tests/e2e/macvtap_test.go:114
    WHEN a macvtap interface is configured as a secondary interface
    /root/go/src/github.com/macvtap-cni/tests/e2e/macvtap_test.go:116
      WHEN a pod requests aforementioned macvtap resource
      /root/go/src/github.com/macvtap-cni/tests/e2e/macvtap_test.go:127
        SHOULD successfully get a second interface, of macvtap type, with configured MAC address [It]
        /root/go/src/github.com/macvtap-cni/tests/e2e/macvtap_test.go:168

        Expected
            <[]tests_test.reportedNetwork | len:1, cap:4>: [
                {
                    Name: "default/macvtap0",
                    Interface: "net1",
                    Mac: "a6:62:96:1b:ad:e3",
                    Dns: {},
                },
            ]
        to have length 2

        /root/go/src/github.com/macvtap-cni/tests/e2e/macvtap_test.go:184

What you expected to happen:
Should pass

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

Additional context:

Environment:

• KubeVirt version (use virtctl version): N/A
• Kubernetes version (use kubectl version): N/A
• VM or VMI specifications: N/A
• Cloud provider or hardware configuration: N/A
• OS (e.g. from /etc/os-release): N/A
• Kernel (e.g. uname -a): N/A
• Install tools: N/A
• Others: N/A

[oshoval]

should be fixed once new multus is released (kubevirtci + cnao bump is required first, since the multus that is deployed is via CNAO iirc)
k8snetworkplumbingwg/network-attachment-definition-client#72
k8snetworkplumbingwg/multus-cni#1341
Thanks

[oshoval]

@maiqueb
We would need please a new multus release that includes this fix
k8snetworkplumbingwg/multus-cni#1341
I guess Doug will create it soon, and just need to wait right ?

Thanks

[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