Uploaded image for project: 'OpenShift Pipelines'
  1. OpenShift Pipelines
  2. SRVKP-2063

Operator webhook configurations continue to expect webhook service to be in openshift-operators namespace even when the operator is installed in a different namespaces

XMLWordPrintable

    • 2
    • False
    • False
    • Pipelines Sprint 216, Pipelines Sprint 217, Pipelines Sprint 218, Pipelines Sprint 219, Pipelines Sprint 220, Pipelines Sprint 221, Pipelines Sprint 222, Pipelines Sprint 223

      Description

      At present, the namespace of webhook service for operator's mutating/validating webhook configuration is hardcoded in the webhook definition yaml. These 2 webhook definitions are not managed by OLM, instead they are created directly by operator's webhook pod. (As knative/pkg webhooks don't work well with OLM - an issue related to generateName vs constantName).

      We need to update the webhookconfiguration logic to find the namespace of the webhooks service (same as namespace of webhook pod) and update that in the mutating/validating webhook configuration before creating them.

      Note

      • This issue will never occur if the operator is installed from OLM UI on OCP OperatorHub.
      • This scenario can occur if a user manually create the operator subscription in a namespace other than openshift-operators
      • This could also happen if some other operator needs Red Hat OpenShift Pipelines (RHOSP) operator as a dependency and OLM installs RHOSP operator in a namespace otherthan openshift-operators. (this needs to be validated)

      Acceptance Criteria

      • If a user install RHOSP operator in a namespace other than `openshift-operators` the mutating/validating webhooks of operator gets updated with namespace information of the webhook service.

              smukhade Shivam Mukhade (Inactive)
              rh-ee-nikthoma Nikhil Thomas
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: