feat: add support for UTF8 labels and rules#7637
feat: add support for UTF8 labels and rules#7637slashpai merged 3 commits intoprometheus-operator:mainfrom
Conversation
|
Working on to support in rules |
|
I am adding a e2e test as well |
|
more changes needed realised after testing e2e locally |
There was a problem hiding this comment.
Options
- Have a global lock on
model.NameValidationSchemebut it's ugly and brittle. - Expose a CLI flag in the operator to choose between legacy and utf8 validation.
- Declare that we only support Prometheus > 3.x from now on.
1 and 2 don't solve the issue of validations in the CRD. Option 3 is a bit extreme.
A middle ground could be:
- We disable all validations on label names in the CRDs (it's the only way we can support UTF-8 label names).
- We set
model.NameValidationScheme = model.UTF8Validationin the operator. - For 3.x versions, the operator doesn't need to perform additional validation because values are always valid UTF-8 strings.
- For 2.x, the operator performs additional validation and reject resources (be it Prometheus, PrometheusRule, ServiceMonitor, ...) which define non-legacy label names.
- It means that we duplicate the logic from prometheus/common but I see no other way to deal with it.
- The user experience degrades for 2.x setups because the API doesn't prevent invalid inputs anymore but at the same time, it encourages migration to 3.x.
- We could think about an option to translate the label names into a legacy-compliant scheme (e.g. replacing invalid characters by "_") instead of rejecting resources but I'm not sure it's worth the effort.
- The admission webhook could have a new option to select which validation scheme it uses (it's straightforward to implement).
Of course, we'd need end-to-end tests to verify the different scenarios.
In parallel we also need to think about Alertmanager and Thanos Ruler...
|
With prometheus/prometheus@0a40df3#diff-b8c18b1e4cc9c9beec1598127742d0a82c9ffb2805996e1887aaa1021ed90587 it looks to be easier to have the option available in operator so current change is based on that |
|
TODO: relabel validations needed to be updated with logic as in prometheus |
IIUC the operator would need to gate on the Prometheus version (for any version not having the ability to configure the validation scheme, the option wouldn't apply and the operator needs to compute the validation scheme applying to the version). |
|
So we have a chicken-and-egg problem because the current CRDs don't allow for utf-8 labels. I'm fine merging this PR as it is and have the end-to-end tests in the follow-up PR which relaxes the validations. |
a952662 to
1c64352
Compare
2fc72fa to
831e0bb
Compare
b10abdb to
a25a762
Compare
|
I was finally able to fix my podman issue to test the change locally as depending CI was taking time, I am debugging the root cause for failure locally |
for admission webhook default is legacy validation Assissted-By: Cursor Signed-off-by: Jayapriya Pai <slashpai9@gmail.com>
|
It should pass now it was issue of promql query it should have been |
Follow-up from prometheus-operator#7637 to complete the UTF8 support for labels Related-to: prometheus-operator#7362 Assisted-by: Cursor Signed-off-by: Jayapriya Pai <slashpai9@gmail.com>
Follow-up from prometheus-operator#7637 to complete the UTF8 support for labels Related-to: prometheus-operator#7362 Assisted-by: Cursor Signed-off-by: Jayapriya Pai <slashpai9@gmail.com>
Follow-up from prometheus-operator#7637 to complete the UTF8 support for labels Related-to: prometheus-operator#7362 Assisted-by: Cursor Signed-off-by: Jayapriya Pai <slashpai9@gmail.com>
Follow-up from prometheus-operator#7637 to complete the UTF8 support for labels Related-to: prometheus-operator#7362 Assisted-by: Cursor Signed-off-by: Jayapriya Pai <slashpai9@gmail.com>
Follow-up from prometheus-operator#7637 to complete the UTF8 support for labels Related-to: prometheus-operator#7362 Assisted-by: Cursor Signed-off-by: Jayapriya Pai <slashpai9@gmail.com>
Related-to #7362
Description
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.
If it fixes a bug or resolves a feature request, be sure to link to that issue.
Type of change
What type of changes does your code introduce to the Prometheus operator? Put an
xin 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
Please check the Prometheus-Operator testing guidelines for recommendations about automated tests.
Changelog entry
Please put a one-line changelog entry below. This will be copied to the changelog file during the release process.