Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

operator: service selectors are vague and overlap with other operators #1676

Closed
petercb opened this issue Mar 3, 2024 · 1 comment · Fixed by #1686
Closed

operator: service selectors are vague and overlap with other operators #1676

petercb opened this issue Mar 3, 2024 · 1 comment · Fixed by #1686
Labels
bug Something isn't working

Comments

@petercb
Copy link

petercb commented Mar 3, 2024

Describe the bug

If you install this operator from the instructions at OperatorHub.io and then install the MetalLB operator (also using the instructions given at OperatorHub.io) they both install into the operators namespace.

This is a problem though because both operators have very similar Service specs:

apiVersion: v1
kind: Service
metadata:
  name: <service>
  namespace: operators 
spec:
  ports:
  - name: "443"
    port: 443
    protocol: TCP
    targetPort: 9443
  selector:
    control-plane: controller-manager
  type: ClusterIP

The result is that traffic to each respective operator service doesn't always go to the right pods.

I think adding a label to the pods and selector of the service something like app: intel-device-plugins would solve this.

To Reproduce

  • Install the intel-device-plugins operator as per the instructions on OperatorHub.io
  • Install the MetalLB operator as per the instructions on OperatorHub.io
  • Install a MetalLB kind or a Device plugin
  • Sometimes the webhook requests will go to the wrong pods

Expected behavior

Traffic from each operators service should only go their pods, this can be achieved by adding more selector labels such as an app one instead of just the control-plane: controller-manager one that currently exists on both. The fact the pods of both answer on 9443 doesn't give k8s much to work on when trying to properly route the traffic.

Screenshots

Error from server (InternalError): error when creating "metallb.yaml": Internal error occurred: failed calling webhook "metallbvalidationwebhook.metallb.io": failed to call webhook: Post "https://metallb-operator-controller-manager-service.operators.svc:443/validate-metallb-io-v1beta1-metallb?timeout=10s": tls: failed to verify certificate: x509: certificate is valid for inteldeviceplugins-controller-manager-service.operators, inteldeviceplugins-controller-manager-service.operators.svc, not metallb-operator-controller-manager-service.operators.svc

System (please complete the following information):

  • OS version: Ubuntu 22.04
  • Kernel version: Linux 5.15
  • Device plugins version: v0.29.0
  • Hardware info: N/A

Additional context
metallb/metallb-operator#431

@tkatila
Copy link
Contributor

tkatila commented Mar 4, 2024

Thanks @petercb for reporting the bug! Your solution proposal seems viable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
2 participants