-
Notifications
You must be signed in to change notification settings - Fork 86
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
feat: workload labels #1065
feat: workload labels #1065
Conversation
75d27cc
to
551cacb
Compare
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.
Relabelling rules looks generally good, but did you intend to change AlertingConfig? Relabeling in Alerting Config only adds labels to alerts, not metrics. Wonder if you meant to do this scrape config section instead? Or am I missing something? 🤔
Tests would be nice for metrics too (unless you meant to do this for alerts).
pkg/operator/operator_config.go
Outdated
SourceLabels: prommodel.LabelNames{"__meta_kubernetes_endpoints_name"}, | ||
Regex: svcNameRE, | ||
}) | ||
cfg.RelabelConfigs = append(cfg.RelabelConfigs, |
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.
Should we ensure there is a dynamic (e.g. config based) switch off for this? e.g. when we block some customer with this?
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.
The design rejected putting this change behind a feature flag, and also suggests that the creation of a feature flag would increase confusion and the maintenance burden for TargetLabels.
An MSA is planned to notify users of this upcoming change and allow them to adjust accordingly.
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 believe the idea is that users before this change are unimpacted since there may be customers already using a label named workload_controller
. The PodMonitoring.targetLabels
field is essentially the switch. This PR is missing that.
@bernot-dev let's update the Defaulter, such that if the customer created a new PodMonitoring (e.g. did not set a targetLabels
value), we add workload_controller
in the list. Then, only add these additional configurations if it is specified (see relabelingsForMetadata
).
e863275
to
94e6d53
Compare
Nope. That was my mistake. Should be fixed now. |
61cf1d8
to
63c43d3
Compare
Implement go/gmp:expand-target-labels.
63c43d3
to
0809cc3
Compare
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.
Love it, thanks! I like this to be implicit for us, so we can iterate and own this (flexibility).
Can we add test for podmonitoring config that filters this out (to check if it's possible for users, I think the agreement was that we want it).
FYI - we're still awaiting final word on if these labels are sufficient cc @xichen2020 |
@pintohutch Is this blocking? |
I don't think it's blocking this PR per se. We may want to wait on final labels before a release though |
Implement go/gmp:expand-target-labels.