Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1990932

Summary: Whereabouts fails in 4.9 due to missing RBAC for leases
Product: OpenShift Container Platform Reporter: Douglas Smith <dosmith>
Component: NetworkingAssignee: Douglas Smith <dosmith>
Networking sub component: multus QA Contact: Weibin Liang <weliang>
Status: CLOSED ERRATA Docs Contact:
Severity: urgent    
Priority: high CC: llopezmo, ngirard, vismishr, weliang
Version: 4.9Keywords: FastFix
Target Milestone: ---   
Target Release: 4.7.z   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1990928 Environment:
Last Closed: 2021-10-20 19:33:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1990928    
Bug Blocks:    

Description Douglas Smith 2021-08-06 15:29:00 UTC 
+++ 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
```
Comment 1 Weibin Liang 2021-10-07 21:00:36 UTC 
[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]$
Comment 6 errata-xmlrpc 2021-10-20 19:33:06 UTC 
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
Comment 7 Douglas Smith 2021-10-28 17:47:53 UTC 
*** Bug 2017983 has been marked as a duplicate of this bug. ***
Comment 8 Lucas López Montero 2021-11-05 15:09:11 UTC 
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
Comment 9 Douglas Smith 2021-11-05 15:20:21 UTC 
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.
Comment 10 Lucas López Montero 2021-11-05 17:06:57 UTC 
Thank you very much for the clarification, Douglas.