-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Feat: add validation for Alertmanager PagerdutyURL in Global Config #7931
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: add validation for Alertmanager PagerdutyURL in Global Config #7931
Conversation
Thanks for doing this! Ideally we'd need end-to-end tests to make sure that it works as expected with the actual admission webhook deployed (similar to the If you feel that it's over your knowledge, we can defer this to a follow-up PR. I'll test locally anyway. |
@simonpasquier Let me try implementing first. I'll let you know if these items have to be deferred to the new PRs. Thank you for your suggestion! |
@simonpasquier I updated E2E test and document already. |
Sorry for the back-and-forth on this PR, my brain is slow to process apparently. Shouldn't we harden the validation of the To give a bit more context, the use case for admission webhooks is to supplement validation which can't be implemented via kubebuilder markers and/or CEL. I'm not saying that we don't need an admission webhook service for Alertmanager CRD but I'd prefer to avoid maintaining it unless it's absolutely required :) prometheus-operator/pkg/apis/monitoring/v1/alertmanager_types.go Lines 469 to 471 in b13fafe
|
@simonpasquier I do agree. It makes more sense to use kube validation instead of maintaining the code in the webhook. Let me close this PR and do what you suggest instead. Thank you! |
Description
This PR adds admission validation for the Alertmanager PagerdutyURL in global configuration.
Type of change
What type of changes does your code introduce to the Prometheus operator? Put an
x
in the box that apply.CHANGE
(fix or feature that would cause existing functionality to not work as expected)FEATURE
(non-breaking change which adds functionality)BUGFIX
(non-breaking change which fixes an issue)ENHANCEMENT
(non-breaking change which improves existing functionality)NONE
(if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)Verification
Unit Tests
Changelog entry