MON-4620: expose remote-write protocol version - #2958
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
|
@simonpasquier: This pull request references MON-4620 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "5.0.0" version, but no target version was set. DetailsIn response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci-robot
added
the
jira/valid-reference
|
Hello @simonpasquier! Some important instructions when contributing to openshift/api: |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Enterprise Run ID: ⛔ Files ignored due to path filters (5)
📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughAdds an optional Suggested reviewers: 🚥 Pre-merge checks | ✅ 14 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (14 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 golangci-lint (2.12.2)Error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented Comment |
openshift-ci
Bot
added
the
size/M
PR Summary by QodoExpose remote-write protocol version in ClusterMonitoringConfig
AI Description
Diagram
High-Level Assessment
Files changed (7)
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@config/v1alpha1/types_cluster_monitoring.go`:
- Around line 1553-1558: Align the RemoteWriteMessageVersion spelling across its
field comments, enum constants, validation marker, and generated CRD, choosing
either the documented Version1.0/Version2.0 form or the currently accepted
V1.0/V2.0 form. Ensure the generated schema and all references consistently
accept and document the same values.
In
`@payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml`:
- Around line 3856-3860: Update the remote write protobuf version schema
description to document the accepted enum values V1.0 and V2.0, matching the
enum entries under this field; do not instruct users to submit Version1.0 or
Version2.0.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 50795f7f-2f8d-4600-90c8-8b822a3f255e
⛔ Files ignored due to path filters (5)
config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yamlis excluded by!**/zz_generated.crd-manifests/*config/v1alpha1/zz_generated.featuregated-crd-manifests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yamlis excluded by!**/zz_generated.featuregated-crd-manifests/**config/v1alpha1/zz_generated.swagger_doc_generated.gois excluded by!**/zz_generated*openapi/generated_openapi/zz_generated.openapi.gois excluded by!openapi/**,!**/zz_generated*openapi/openapi.jsonis excluded by!openapi/**
📒 Files selected for processing (2)
config/v1alpha1/types_cluster_monitoring.gopayload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml
| // messageVersion defines the Remote Write message's version to use when writing to the endpoint. | ||
| // When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time. | ||
| // When set to "Version1.0", Prometheus uses the `prometheus.WriteRequest` protobuf message introduced in Remote Write 1.0. | ||
| // When set to "Version2.0", Prometheus uses the `io.prometheus.write.v2.Request` protobuf message introduced in Remote Write 2.0. | ||
| // +optional | ||
| MessageVersion RemoteWriteMessageVersion `json:"messageVersion,omitzero"` |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
Align the documented values with the enum values.
The field documentation says users should set "Version1.0" or "Version2.0", but validation accepts only "V1.0" and "V2.0". A client following the documentation will be rejected by the CRD. Choose one spelling and use it consistently in the comments, constants, validation marker, and generated CRD.
Also applies to: 1760-1764
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@config/v1alpha1/types_cluster_monitoring.go` around lines 1553 - 1558, Align
the RemoteWriteMessageVersion spelling across its field comments, enum
constants, validation marker, and generated CRD, choosing either the documented
Version1.0/Version2.0 form or the currently accepted V1.0/V2.0 form. Ensure the
generated schema and all references consistently accept and document the same
values.
| When set to "Version1.0", Prometheus uses the `prometheus.WriteRequest` protobuf message introduced in Remote Write 1.0. | ||
| When set to "Version2.0", Prometheus uses the `io.prometheus.write.v2.Request` protobuf message introduced in Remote Write 2.0. | ||
| enum: | ||
| - V1.0 | ||
| - V2.0 |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Document the enum values accepted by the schema
The descriptions say to use Version1.0 and Version2.0, but the enum only accepts V1.0 and V2.0. Users following this documentation will submit rejected resources.
Proposed fix
- When set to "Version1.0", Prometheus uses the `prometheus.WriteRequest` protobuf message introduced in Remote Write 1.0.
- When set to "Version2.0", Prometheus uses the `io.prometheus.write.v2.Request` protobuf message introduced in Remote Write 2.0.
+ When set to "V1.0", Prometheus uses the `prometheus.WriteRequest` protobuf message introduced in Remote Write 1.0.
+ When set to "V2.0", Prometheus uses the `io.prometheus.write.v2.Request` protobuf message introduced in Remote Write 2.0.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| When set to "Version1.0", Prometheus uses the `prometheus.WriteRequest` protobuf message introduced in Remote Write 1.0. | |
| When set to "Version2.0", Prometheus uses the `io.prometheus.write.v2.Request` protobuf message introduced in Remote Write 2.0. | |
| enum: | |
| - V1.0 | |
| - V2.0 | |
| When set to "V1.0", Prometheus uses the `prometheus.WriteRequest` protobuf message introduced in Remote Write 1.0. | |
| When set to "V2.0", Prometheus uses the `io.prometheus.write.v2.Request` protobuf message introduced in Remote Write 2.0. | |
| enum: | |
| - V1.0 | |
| - V2.0 |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml`
around lines 3856 - 3860, Update the remote write protobuf version schema
description to document the accepted enum values V1.0 and V2.0, matching the
enum entries under this field; do not instruct users to submit Version1.0 or
Version2.0.
Code Review by Qodo
1. messageVersion docs mismatch enum
|
![qodo-for-rh-openshift[bot]](https://avatars.githubusercontent.com/u/792337?s=60&v=4){kind=small}
| // messageVersion defines the Remote Write message's version to use when writing to the endpoint. | ||
| // When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time. | ||
| // When set to "Version1.0", Prometheus uses the `prometheus.WriteRequest` protobuf message introduced in Remote Write 1.0. | ||
| // When set to "Version2.0", Prometheus uses the `io.prometheus.write.v2.Request` protobuf message introduced in Remote Write 2.0. | ||
| // +optional | ||
| MessageVersion RemoteWriteMessageVersion `json:"messageVersion,omitzero"` |
There was a problem hiding this comment.
1. messageversion docs mismatch enum 📜 Skill insight ≡ Correctness
The new messageVersion field documentation tells users to set Version1.0/Version2.0, but kubebuilder enforces the enum values V1.0/V2.0, so users following the docs will submit invalid configuration and have their ClusterMonitoringConfig rejected. This creates a direct contradiction between documented behavior and validation constraints.
Agent Prompt
## Issue description
The `remoteWrite[].messageVersion` field documentation advertises values `"Version1.0"` / `"Version2.0"`, but the actual kubebuilder/CRD enum validation only permits `"V1.0"` / `"V2.0"`, causing configs written per the docs to be rejected.
## Issue Context
This is a docs-vs-validation contradiction (disallowed by PR Compliance ID 1509) and will lead to user-facing validation failures when applying `ClusterMonitoringConfig`. The source Go type defines `RemoteWriteMessageVersion` with `+kubebuilder:validation:Enum=V1.0;V2.0` and corresponding constants, while generated artifacts (CRDs, swagger, OpenAPI) will reflect those enforced enum values; updating the source comment (or, alternatively, changing the enum/constants) and regenerating is needed so every published artifact matches one consistent convention.
## Fix Focus Areas
- config/v1alpha1/types_cluster_monitoring.go[1553-1558]
- config/v1alpha1/types_cluster_monitoring.go[1756-1765]
- config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yaml[3852-3861]
- config/v1alpha1/zz_generated.featuregated-crd-manifests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml[3852-3861]
- payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml[3852-3861]
- config/v1alpha1/zz_generated.swagger_doc_generated.go[635-640]
- openapi/generated_openapi/zz_generated.openapi.go[26821-26828]
- openapi/openapi.json[14770-14774]
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Signed-off-by: Simon Pasquier <spasquie@redhat.com>
| // When set to "Version1.0", Prometheus uses the `prometheus.WriteRequest` protobuf message introduced in Remote Write 1.0. | ||
| // When set to "Version2.0", Prometheus uses the `io.prometheus.write.v2.Request` protobuf message introduced in Remote Write 2.0. |
There was a problem hiding this comment.
Based on the enum constraints, "Version1.0" and "Version2.0" would be rejected inputs. Either align this text with the actual allowed inputs or update the allowed inputs to match these documented strings.
| // +kubebuilder:validation:XValidation:rule="self.matches('^[a-zA-Z0-9_-]+$')",message="must contain only alphanumeric characters, hyphens, and underscores" | ||
| Name string `json:"name,omitempty"` | ||
| // messageVersion defines the Remote Write message's version to use when writing to the endpoint. | ||
| // When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time. |
There was a problem hiding this comment.
What is the current default behavior?
|
@simonpasquier: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
3 participants
No description provided.