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
MON-3216: Add ownership labels to kube resources #1986
Conversation
4a768b1
to
86e44d8
Compare
/retitle MON-3216: Add ownership labels to kube resources |
@machine424: This pull request references MON-3216 which is a valid jira issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
I'll be simulating an upgrade on a cluster, this shouldn't break controllers as I made sure to only ADD labels. |
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.
I think that we can accomplish the same with less modifications to the jsonnet files and a 100% coverage:
6106f35
to
f8aaf5e
Compare
@machine424: This pull request references MON-3216 which is a valid jira issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
sgtm
is it possible to extend jsonnet/utils/add-labels.libsonnet and support *List objects?
Are you talking about the resources managed by the Prometheus operator (e.g. Prometheus, Alertmanager & ThanosRuler)? We could pass the --labels argument to inject labels in the child resources. |
Yep, we do sth like that in add-annotations.libsonnet, but as I see it it'll make the util complicated, so maybe in another PR (or the next time someone asks for those resources)
Yep, (and maybe others managed by other operators), it'd be great to have |
I'm afraid it will be never then 😝 |
or |
/jira refresh |
@machine424: This pull request references MON-3216 which is a valid jira issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
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.
One nit, otherwise this looks good.
jsonnet/utils/add-labels.libsonnet
Outdated
else | ||
'cluster-monitoring-operator', | ||
|
||
addLabels(o, labels): { |
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.
addLabels(o, labels): { | |
addLabels(labels,o ): { |
Nit but what do you think of swapping the arguments here. I think that would improve readability in the main file. Other wise we have
addLabels(
...32 lines...,
$labelsToAdd)
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.
done
and "app.kubernetes.io/part-of" labels on Kube resources created and managed by CMO and CVO. See https://issues.redhat.com/browse/MON-3216 for the whys. We chose this "inject at the end" approach as it requires less changes and is future-proof, but we're aware that: - We need to label resources managed by CVO individually (see utils/add-labels.libsonnet) - Items of a XXXList (RoleList in role-specific-namespaces.yaml for example) are missed - Resources created by some CR MAY be missed (as we don't tell their operators to add the labels) A draft of the other approach (Add the labels explicitly to each resource) can be found at 5386735#diff-3f0ac462e0855b3c5693e93fd73febeec9422783681a4a15b2a82f9f40efec89, with this approcah we can get better coverage, we have better control but it's harder to maintain and is more intrusive. Signed-off-by: Ayoub Mrini <amrini@redhat.com>
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.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jan--f, machine424 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@machine424: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
…-operator, during 4.13->4.14 upgrade The option --labels was set to the prometheus-operator in openshift#1986 to make it add the label "app.kubernetes.io/part-of: openshift-monitoring" to resources it creates. prometheus-operator adds the labels to some controllers matchLabels as well (to the prometheus statefulset e.g.) which makes the prometheus-operator recreate the statefulset as matchLabels is an immutable field. Recreating the statefulset leads to downtime as the prometheus-operator run the deletion in a foreground mode, check prometheus-operator/prometheus-operator#3875 for the whys. We consider that adding the ownership labels is not worth the downtime, and we'll be thinking of a way to avoid it.
…-operator, during 4.13->4.14 upgrade The option --labels was set to the prometheus-operator in openshift#1986 to make it add the label "app.kubernetes.io/part-of: openshift-monitoring" to resources it creates. prometheus-operator adds the labels to some controllers matchLabels as well (to the prometheus statefulset e.g.) which makes the prometheus-operator recreate the statefulset as matchLabels is an immutable field. Recreating the statefulset leads to downtime as the prometheus-operator run the deletion in a foreground mode, check prometheus-operator/prometheus-operator#3875 for the whys. We consider that adding the ownership labels is not worth the downtime, and we'll be thinking of a way to avoid it. Of course, this will lead to the recreation of these resources if openshift#1986 is alredy deployed.
Generalize the use of recommended "app.kubernetes.io/managed-by" and "app.kubernetes.io/part-of" labels on Kube resources created and managed by CMO and CVO.
See https://issues.redhat.com/browse/MON-3216 for the whys.
We chose this "inject at the end" approach as it requires less changes, but
we're aware that:
A draft of the other approach (Add the labels explicitly to each resource) can be found at
machine424@5386735#diff-3f0ac462e0855b3c5693e93fd73febeec9422783681a4a15b2a82f9f40efec89, with this approcah we can get better coverage, we have better control
but it's harder to maintain and is more intrusive.