+++ This bug was initially created as a clone of Bug #1990928 +++ +++ This bug was initially created as a clone of Bug #1989734 +++ Description of problem: Whereabouts fails Version-Release number of selected component (if applicable): 4.9 How reproducible: Always. Steps to Reproduce: 1. Create net-attach-def using whereabouts, such as: ``` apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: macvlan-conf spec: config: '{ "cniVersion": "0.3.0", "type": "macvlan", "master": "ens4", "mode": "bridge", "ipam": { "type": "whereabouts", "range": "198.18.0.0/15" } }' ``` 2. Create some pods that reference it: ``` ``` 3. If the pods do not come up, you've encountered it. If the pods come up, it's working. Actual results: Pods don't come up. Expected results: Pods come up (with properly assigned IPs) --- Additional comment from Douglas Smith on 2021-08-03 20:03:39 UTC --- Missing from step #2 above: ``` apiVersion: apps/v1 kind: ReplicaSet metadata: name: whereabouts-test labels: app: whereabouts-test tier: whereabouts-test spec: # modify replicas according to your case replicas: 3 selector: matchLabels: tier: whereabouts-test template: metadata: labels: tier: whereabouts-test annotations: k8s.v1.cni.cncf.io/networks: macvlan-conf spec: containers: - name: samplepod command: ["/bin/ash", "-c", "trap : TERM INT; sleep infinity & wait"] image: quay.io/dougbtv/alpine:latest ```
[weliang@weliang tmp]$ oc get pods NAME READY STATUS RESTARTS AGE multus-macvlan-pod-644b94f5f9-6sltm 1/1 Running 0 20s multus-macvlan-pod-644b94f5f9-vk6ww 1/1 Running 0 20s multus-macvlan-pod-644b94f5f9-xrvj9 1/1 Running 0 20s [weliang@weliang tmp]$ oc get clusterversion NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.7.0-0.ci.test-2021-10-07-201640-ci-ln-j3zcr4k-latest True False 8m41s Cluster version is 4.7.0-0.ci.test-2021-10-07-201640-ci-ln-j3zcr4k-latest [weliang@weliang tmp]$
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 (OpenShift Container Platform 4.7.34 bug fix update), 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-2021:3824
*** Bug 2017983 has been marked as a duplicate of this bug. ***
We have a production cluster on version 4.7.33 experiencing this problem, we have manually configured RBAC as described on the pull request [1] as a workaround and it works. So far so good. However; when we upgrade to 4.7.34 or a later version, I would assume there will be an "AlreadyExists" error because the RBAC configuration has been already set. Is this correct? Will that imply any problem during or after the eventual upgrade to 4.7.34 (or later)? Thank you for your help. [1] https://github.com/openshift/cluster-network-operator/pull/1186/files#diff-527b1b0eb2d5eb12b3830bbc2a3c834c62e447cdab04f0f080d57b27e34f4933
Lucas -- I believe the cluster-network-operator should be able to reconcile the objects that it templates. That is, the cluster-network-operator should account for already existing resources and update them (or leave them alone if they match). So I don't believe it should be a problem to leave those custom-created RBAC rules for the work, such as those you've created which are similar/the same as those patch that you've linked.
Thank you very much for the clarification, Douglas.