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
Add monitoring-edit role #754
Add monitoring-edit role #754
Conversation
cc @openshift/openshift-team-monitoring |
- monitoring.coreos.com | ||
resources: | ||
- servicemonitors | ||
- podmonitors |
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.
maybe I'm missing context, but I would have expected a role for monitoring configurations, that is not just about targets but both scraping and alerting configuration
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.
For configuration we specified a dedicated role, see https://github.com/openshift/enhancements/blob/master/enhancements/monitoring/user-workload-monitoring.md#monitoring-targets-edit, and https://github.com/openshift/enhancements/blob/master/enhancements/monitoring/user-workload-monitoring.md#monitoring-workload-config-edit:
monitoring-targets-edit
: This is a cluster role which can be bound against a concrete namespace by the cluster admin. Embeds the get/create/edit/delete permissions for the following custom resources:
- ServiceMonitor
- PodMonitor
- PrometheusRule
It allows to create new scraping targets for services/pods and allows to create new recording or alerting rules.
monitoring-workload-config-edit
:
This is a named role against the workload-monitoring-config configmap resource in the openshift-monitoring namespace embedding get/create/edit/delete permissions.
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.
Or did we miss something else here? 🤔
- monitoring.coreos.com | ||
resources: | ||
- servicemonitors | ||
- podmonitors |
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.
according to the OEP we need to have PrometheusRule
here too.
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.
on an after-thought: I believe we added PrometheusRule too much in the enhancement proposal, because as per https://issues.redhat.com/browse/MON-936?focusedCommentId=13977634&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13977634 this refers only to ServiceMonitor/PodMonitor custom resources. We should submit a PR against the enhancement.
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.
This is what I meant. I think PrometheusRule should be part of this, although then just "targets" doesn't make sense.
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 can unify monitoring-rules-edit
and monitoring-targets-edit
, but that would imply that the user cannot be given distinct permissions to silence alerts.
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.
People can still create those roles if they need but I don't see a standard use case where the distinction needs to be present. The basic use case is self service monitoring, and a user will always need both for that.
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've added a comment to the Jira ticket for Christian.
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.
@simonpasquier we reached consensus that we need to add prometheusrule
custom resources here. The OEP doesn't need an update as it specifies that already.
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 there is a small change that we should do though, which is change the naming, as this doesn't reflect just targets. How about just monitoring-config-edit
?
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 agree about changing the name. The OEP already provisions a monitoring-workload-config-edit role so having monitoring-config-edit
might be confusing?
Maybe simply monitoring-edit
?
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'm happy with monitoring-edit
as well.
559daff
to
59ef25e
Compare
59ef25e
to
af6a5b4
Compare
@@ -37,7 +37,7 @@ spec: | |||
) | |||
for: 5m | |||
labels: | |||
severity: critical |
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.
jsonnet file lock did not change? 🤔
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.
Also no need to bump this, as I will do as part of the release checklist thing.
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.
this is what happens when you push code changes during a meeting 😄
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.
haha :D
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
af6a5b4
to
ef99daf
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.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lilic, simonpasquier 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 |
/hold cancel |
/retest Please review the full test history for this PR and help us cut down flakes. |
8 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. |
/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. |
/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. |
/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. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/label qe-approved |
No description provided.