You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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):
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: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
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 thecontrol-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
System (please complete the following information):
Additional context
metallb/metallb-operator#431
The text was updated successfully, but these errors were encountered: