Description of problem: Whereabouts IPAM CNI should use CR in whereabouts.cni.cncf.io Version-Release number of selected component (if applicable): 4.5.0-0.nightly-2020-03-10-155709 How reproducible: Always Steps to Reproduce: 1. curl -s https://raw.githubusercontent.com/weliang1/Openshift_Networking/master/Features/multus/whereabouts-macvlan.yaml | oc create -f- 2. curl -s https://raw.githubusercontent.com/weliang1/Openshift_Networking/master/Features/multus/pod.yaml | sed s/pod-name/pod-macvlan-bridge-whereabouts/g | sed s/net-attach-def/macvlan-bridge-whereabouts/g | oc create -f- Actual results: Warning FailedCreatePodSandBox 11s kubelet, ip-10-0-145-60.us-east-2.compute.internal Failed to create pod sandbox: rpc error: code = Unknown desc = failed to create pod network sandbox k8s_pod-macvlan-bridge-whereabouts_test_651a9a80-5349-4c9a-91cf-31eeb73f5b53_0(e4a9b1c372188fbb47187a3636043942098c962924f0d6f1fce9f614978e9533): Multus: [test/pod-macvlan-bridge-whereabouts]: error adding container to network "whereabouts": delegateAdd: error invoking DelegateAdd - "macvlan": error in getting result from AddNetwork: Error assigning IP: no matches for kind "IPPool" in version "whereabouts.cni.k8s.io/v1alpha1" Expected results: Pod should get correct IP address for second interface Additional info:
Same issue happened in 4.4.0-0.nightly-2020-03-11-095741
I found an additional bug while fixing this one, BZ @ https://bugzilla.redhat.com/show_bug.cgi?id=1812676
Modified in https://github.com/openshift/whereabouts-cni/pull/7
Tested and verified in 4.5.0-0.nightly-2020-04-21-103613 [weliang@weliang ~]$ oc get pods NAME READY STATUS RESTARTS AGE pod-macvlan-bridge-whereabouts 1/1 Running 0 2m [weliang@weliang ~]$ [weliang@weliang ~]$ oc rsh pod-macvlan-bridge-whereabouts / # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 3: eth0@if30: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 8951 qdisc noqueue state UP link/ether 0a:58:0a:83:00:19 brd ff:ff:ff:ff:ff:ff inet 10.131.0.25/23 brd 10.131.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::7821:3dff:fe92:6866/64 scope link valid_lft forever preferred_lft forever 4: net1@if2: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 9001 qdisc noqueue state UP link/ether 52:0c:f8:c8:ce:31 brd ff:ff:ff:ff:ff:ff inet 192.168.2.225/28 brd 192.168.2.239 scope global net1 valid_lft forever preferred_lft forever inet6 fe80::500c:f8ff:fec8:ce31/64 scope link valid_lft forever preferred_lft forever
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2409