-
Notifications
You must be signed in to change notification settings - Fork 368
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
Allow user workload monitoring configuration ConfigMap to be created in UWM ns #804
Allow user workload monitoring configuration ConfigMap to be created in UWM ns #804
Conversation
lilic
commented
Jun 9, 2020
•
edited
Loading
edited
- I added CHANGELOG entry for this change.
dbef134
to
f8f027e
Compare
/retest
strange failure... |
/retest |
f8f027e
to
4e233a2
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.
cc @openshift/openshift-team-monitoring this is ready for a first pass, please take a look, I still need to update the CHANGELOG and add an example after it looks good from you.
cmd/operator/main.go
Outdated
@@ -89,6 +89,7 @@ func Main() int { | |||
namespaceUserWorkload := flagset.String("namespace-user-workload", "openshift-user-workload-monitoring", "Namespace to deploy and manage user workload monitoring stack in.") | |||
namespaceSelector := flagset.String("namespace-selector", "openshift.io/cluster-monitoring=true", "Selector for namespaces to monitor.") | |||
configMapName := flagset.String("configmap", "cluster-monitoring-config", "ConfigMap name to configure the cluster monitoring stack.") | |||
userWorkloadConfigMapName := flagset.String("userWorkloadConfigmap", "user-workload-monitoring-config", "ConfigMap name to configure the user workload monitoring stack.") |
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.
why does this need to be configurable?
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.
Just followed pattern we had, see line above here, honestly happy to leave it out as well!
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.
my intuition is we should limit exposure here as we want to move to a CRD based setup 🤔
This cli flag increases the public API surfaces.
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.
good point, removed it!
looking great so far! 🎉 |
08b56d1
to
cbd1e28
Compare
/lgtm |
cbd1e28
to
b1297c0
Compare
b1297c0
to
7b4146d
Compare
@s-urbaniak PTAL changes since last time:
Thanks! |
/hold cancel |
/retest |
userCM, err := o.client.GetConfigmap(o.namespaceUserWorkload, o.userWorkloadConfigMapName) | ||
if err != nil { | ||
if apierrors.IsNotFound(err) { | ||
klog.Warning("No User Workload Monitoring ConfigMap was found. Using defaults.") |
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.
Info
rather than Warning
?
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.
We use warning level for the cluster monitoring configmap, I just followed that pattern. It makes sense to me in a way, as you are warning user they did not configure their stack at all. But don't have too strong opinion so can change, but then we should do both?
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'd rather have the message at the info level because for me a warning is something I need at least to investigate and not customizing the monitoring isn't something suspicious. At info, the message would still logged so it would be available for support requests.
And +1000 that if we change it here, it should be consistent across the board.
return uwc, nil | ||
} | ||
|
||
klog.Warning("No User Workload Monitoring ConfigMap was found. Using defaults.") |
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.
ditto?
PrometheusK8sConfig *PrometheusK8sConfig `json:"prometheusK8s"` | ||
PrometheusUserWorkloadConfig *PrometheusK8sConfig `json:"prometheusUserWorkload"` | ||
ClusterMonitoringConfiguration *ClusterMonitoringConfiguration `json:"-"` | ||
UserWorkloadConfiguration *UserWorkloadConfiguration `json:"-"` |
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.
Having both UserWorkloadConfiguration
and UserWorkloadConfig
is confusing.
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.
UserWorkloadConfig?
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.
We have a UserWorkloadConfig
struct:
cluster-monitoring-operator/pkg/manifests/config.go
Lines 157 to 159 in 882dc1b
type UserWorkloadConfig struct { | |
Enabled *bool `json:"enabled"` | |
} |
And another UserWorkloadConfiguration
struct:
cluster-monitoring-operator/pkg/manifests/config.go
Lines 381 to 385 in 882dc1b
type UserWorkloadConfiguration struct { | |
PrometheusOperator *PrometheusOperatorConfig `json:"prometheusOperator"` | |
Prometheus *PrometheusK8sConfig `json:"prometheus"` | |
ThanosRuler *ThanosRulerConfig `json:"thanosRuler"` | |
} |
The names are close which makes it confusing for me when reviewing the code.
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 see, makes sense! Any suggestions for new or old name?
ThanosQuerierConfig *ThanosQuerierConfig `json:"thanosQuerier"` | ||
UserWorkloadEnabled *bool `json:"enableUserWorkload"` | ||
// TODO: Remove in 4.7 release. | ||
PrometheusUserWorkloadConfig *PrometheusK8sConfig `json:"prometheusUserWorkload"` |
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.
Instead of duplicating PrometheusUserWorkloadConfig
, PrometheusOperatorUserWorkloadConfig
and ThanosRulerConfig
here and in UserWorkloadConfiguration
maybe it would be simpler to use only UserWorkloadConfiguration
? IOW handle the "legacy" fields only when loading the config map but don't expose them here.
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 point was to be able to easily remove the current logic (we will just remove it after 4.7), hence the TODO comments, as we will stop supporting this in 4.7. And to separate out the two clear tenants we have right now cluster and user workload.
If you have a better suggestion, can yon clarify, thanks! :)
IOW? :)
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.
An alternative approach would be to remove the user workload monitoring fields from the ClusterMonitoringConfiguration
struct and only use Config.UserWorkloadConfiguration
. NewConfig()
would try to load the uwm fields until we decide that it shouldn't.
Something like this: simonpasquier@44bd3dd
The side effect is that uwm configuration will be taken either from the "legacy" fields or from the new configmap in openshift-user-workload-monitoring
but it won't be a merge of both. In the current state, PrometheusOperatorConfig
can be defined in the openshift-montoring
configmap and PrometheusConfig
in the openshift-user-workload-monitoring
configmap, it can be confusing or desired, depending on how you see things :)
(IOW: in other words)
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.
hmm .. especially with configuration I much prefer duplication structs. This is a lesson learned the hard way in Kubernetes. Only because things happen to be identical at this point in time, doesn't mean they may not very well develop in different direction in the future, and they almost always do unless the concept is literally the same (eg. TLS configuration in Prometheus). In this case we even know it will be deleted in the future, so I actually prefer @lilic 's currently proposed way.
|
||
// TODO: remove after 4.7 | ||
|
||
if f.config.ClusterMonitoringConfiguration.PrometheusUserWorkloadConfig.LogLevel != "" { |
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.
When you have config fields defined both in f.config.ClusterMonitoringConfiguration
and f.config.UserWorkloadConfiguration
then the former will take precedence. Couldn't this cause confusion?
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.
techPreview is what we have to support right now primarily hence why it takes precedence here, but that is a good point to document.
openshift-user-workload-monitoring namespace
7b4146d
to
882dc1b
Compare
/retest |
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: brancz, lilic, s-urbaniak 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 |
/retest Please review the full test history for this PR and help us cut down flakes. |
2 similar comments
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |