odo link flow broken on latest SBO 0.10.

[kadel]

https://github.com/redhat-developer/service-binding-operator/releases/tag/v0.10.0

Latest SBO introduced changes that required explicitly create RoleBindings in order for SBO to be able to read information from CustomResources.

Ideally this RoleBinding should be automaticaly created when Operator that supports ServiceBinding gets installed.
But currently there are no Operator that would support SBO out of the box.

This means that when someone installs Operator that they want to use with SBO with, they need to create RoleBinding manually. This needs to be done with cluster admin privileges.

For example this is ClusterRole required for postresql from dev4devs operator.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: postgresql-binding
  labels:
    service.binding/controller: "true"
rules:
  - apiGroups:
      - postgresql.dev4devs.com
    resources:
      - databases
    verbs:
      - get
      - list

---

apiVersion: rbac.authorization.k8s.io/v1        
kind: ClusterRoleBinding
metadata:
  name: postgresql-binding-sbo
subjects:
- kind: ServiceAccount
  name: service-binding-operator
  namespace: openshift-operators
roleRef:
  kind: ClusterRole
  name: postgresql-binding
  apiGroup: rbac.authorization.k8s.io

We need to document this in odo docs. As without this users won't be able to use odo link with SBO.

/priority critical

[kadel]

Something that we could consider is to drop SBO use form odo, and just use the client side library (linking without operator), even if the SBO is installed on the cluster.

Currently there is no real benefit for using the Service Binding Operator. There are no operators that are using SBO, so user needs to define binding on their own anyway.

Not supporting the operator approach for now would also have a good inpact on odo link stability, as SBO api is unstable and it is breaking with every release.
This would be just temporarly, once SBO api is stable and usable, and there are operators that can be used out of the box, we would enable option for using the Operator again.

[scottkurz]

One more note: IIUC, the SBO is not correctly watching the managed CR for changes:
redhat-developer/service-binding-operator#970
taking away yet another benefit for using SBO, until this is fixed.

[feloy]

• Disable the test that SBO is running on the cluster, always use the library
• Keep the code for SBO use, we will use it later
• Remove SBO from clusters