prometheus-operator
enhancement: allow toggling custom config deprecation behaviour
Description
Allow toggling custom config deprecation behaviour; helpful in scenarios where a controller disables all service discovery methods.
Type of change
- [ ]
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) - [x]
ENHANCEMENT(non-breaking change which improves existing functionality) - [ ]
NONE(if none of the other choices apply. Example, tooling, build system, CI, docs, etc.)
Changelog entry
Users can toggle Prometheus controller's custom configuration deprecation behavior using the "--deprecate-custom-configuration" flag.
Not sure I understand what the flag is for, can you elaborate a bit? I lack the context behind this.
To provide more context, there's a legacy behavior which instructs the operator to not manage the Prometheus configuration when all selectors (ruleSelector, serviceMonitorSelector, ...) are nil. In this case, the user is supposed to build by hand the secret holding the (gzipped) configuration. It can be a pain to debug if you run into this mode by accident because the operator doesn't complain but the Prometheus statefulset will never spin up pods if the secret is missing. This is very much deprecated now since we have additionalScrapeConfigs + ScrapeConfig CRD but removing it would break users. Adding a flag to say "don't support unamanaged configuration mode" improves the UX.
This PR is rebased on https://github.com/prometheus-operator/prometheus-operator/pull/6992 to address an issue that crashed the make generate target.