Skip to content

fix: give OMJob operator its own selector labels#488

Open
srlightbody wants to merge 1 commit intoopen-metadata:mainfrom
srlightbody:fix/service-selector
Open

fix: give OMJob operator its own selector labels#488
srlightbody wants to merge 1 commit intoopen-metadata:mainfrom
srlightbody:fix/service-selector

Conversation

@srlightbody
Copy link
Copy Markdown
Contributor

Fixes #482

The operator deployment uses OpenMetadata.selectorLabels which gives it the same app.kubernetes.io/name and app.kubernetes.io/instance labels as the server. Since the server Service also selects on those labels, it matches both server and operator pods.

The operator is a separate application - it should have its own name label. This PR changes the operator pod template and selector to use app.kubernetes.io/name: openmetadata-omjob-operator instead of inheriting the shared openmetadata name. It keeps the same release instance label and component label for Helm ownership tracking.

Only the operator deployment template is modified. The server deployment, service, and helpers are untouched.

The operator deployment was using OpenMetadata.selectorLabels (name +
instance) which are the same labels used by the server deployment and
service. This caused the server's service to match operator pods in
addition to server pods.

The operator is a separate application and should have its own name
label. Changed from inheriting the shared selectorLabels to using
its own name (openmetadata-omjob-operator) while keeping the same
release instance label and component label.

Fixes open-metadata#482
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Service selector matches OMJob Operator pods in addition to server pods

1 participant