-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
[grafana] Use .Values.podLabels
in service definition.
#3105
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ikogan Could you please sign the DCO ? Thanks!
.Values.podLabels
in service definition..Values.podLabels
in service definition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
grafana.selectorLabels
should still sufficient for matching pods
@jkroepke That's right! but what if the some users find it more convinient to include the labels directly from the |
No. The helper If The currently implementation is fine and should not be changed in my opinion. |
For the DCO, do you just want an empty commit with the sign-off or to amend the one commit I made for this? |
By "the current implementation" do you mean in the PR or in main? |
current implementation in main. You can add additional pod labels on your choice, however not all labels must be defined in a selector on a service. |
That's correct! seems like I mistaken it for something else. |
@jkroepke guess we're closing this then ? |
But doesn't this mean that if you use |
Please, explain, why the service would be broken? The service selector based on |
Sorry, it's been a minute since I had the issue and I had my issue wrong. Since I'm deploying Grafana as a subchart of another chart, the I don't see a way in the helm chart to impact the selector labels that the service uses. Right now my only recourse is to disable the service entirely and generate my own. |
This case happens if your umbralla chart contains multiple charts named grafana? Because of part of the grafana selector labels named For such scenarios,
That case, you current deployment strategy is broken. If helm-charts/charts/grafana/templates/deployment.yaml Lines 21 to 23 in 323e843
If we are merging this PR, this issue would more hidden and lead to undefined behavior in Kubernetes. Note You should not create other Pods whose labels match this selector, either directly, by creating another Deployment, or by creating another controller such as a ReplicaSet or a ReplicationController. If you do so, the first Deployment thinks that it created these other Pods. Kubernetes does not stop you from doing this. Ref: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#selector To address that kind of issue, |
It contains a single chart named Grafana but I'm also adding oncall as a subchart. This causes all of the oncall deployments to have the same pod labels. In my values, I simply have app.kubernetes.io/name: grafana
app.kubernetes.io/instance: grafana You're right that this all runs deeper than the |
But that is strange. Is the sub-chart name of oncall, grafana too? Did you define
|
Currently, if you set
.Values.podLabels
in yourvalues.yaml
, they are not reflected in the service selectors so traffic does not reach Grafana pods.This simply adds
.Values.podLabels
to the service selectors.