OLM generates duplicate service for webhooks if name does not match deployment

[amisevsk]

Bug Report

What did you do? Deploy an operator with

• A service with port 443, pointing at the controller deployment's conversion webhooks port
• A CSV with webhookDefinitions for conversion webhooks referencing the controller deployment by name.

What did you expect to see? OLM uses the existing service in the bundle to configure conversion webhooks on CRDs.

What did you see instead? Under which circumstances? OLM creates a duplicate service with the same configuration as the provided service to match the controller deployment name. E.g. in my case, I end up with

• A deployment, named devworkspace-controller-manager
• A service (from the bundle) named devworkspace-controller-service
• A service (created by OLM, presumably) named devworkspace-controller-manager-service, with the same exposed ports as the service above.

Environment

• operator-lifecycle-manager version:

Not sure how to get this info; whatever ships with OpenShift 4.7.2

• Kubernetes version information:

Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.4", GitCommit:"d360454c9bcd1634cf4cc52d1867af5491dc9c5f", GitTreeState:"clean", BuildDate:"2020-11-11T13:17:17Z", GoVersion:"go1.15.2", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.0+5fbfd19", GitCommit:"5fbfd197c16d3c5facbaa1d7b9f3ea58cf6b36e9", GitTreeState:"clean", BuildDate:"2021-02-17T15:21:33Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes cluster kind: OpenShift

Additional context This is mostly a point of friction between Operator SDK and OLM. To generate a CSV with webhookDefinitions, the Operator SDK requires:

• A service to exist, exposing a port that matches one of the ports on a deployment
• A CRD that references that service in it's .spec.conversion section

This gets converted to a CSV whose webhookDefinitions reference the deployment by name directly, skipping the deployment. When the CSV is processed, it results in a separate service being created, with name <deploymentName>-service, even if the service used by Operator SDK has a different name.

The only way to avoid a duplicate service is to look at what OLM does, and then name your service accordingly.

[exdx]

The reason the service is duplicated is because OLM generates APIServices and Webhooks in a very similar way - by providing a port on the CSV OLM generates a service. There's no clear way to change this behavior since other operator CSV's rely on OLM creating a service for their Webhooks and APIServices.

That being said the SDK <-> OLM behavior around webhooks should be consistent, should triage this further.

[amisevsk]

To further add to the confusion caused by this behaviour -- to avoid a duplicate service, I changed the name we use to match what's expected by OLM (i.e. devworkspace-controller-manager-service), but I also added another port to support metrics (rather than have two services that point at the same deployment). In this case, OLM overwrites the perfectly acceptable service's ports, removing my metrics port:

The file in bundle/manifests

apiVersion: v1
kind: Service
spec:
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: conversion
  - name: metrics
    port: 8443
    targetPort: metrics

The service created when installing the operator

apiVersion: v1
kind: Service
spec:
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: conversion