Skip to content

MON-4620: expose remote-write protocol version - #2958

Open
simonpasquier wants to merge 1 commit into
openshift:masterfrom
simonpasquier:MON-4620
Open

MON-4620: expose remote-write protocol version#2958
simonpasquier wants to merge 1 commit into
openshift:masterfrom
simonpasquier:MON-4620

Conversation

@simonpasquier

Copy link
Copy Markdown
Contributor

No description provided.

@openshift-merge-bot

Copy link
Copy Markdown
Contributor

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

@openshift-ci-robot

openshift-ci-robot commented Jul 27, 2026

Copy link
Copy Markdown

@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.

Details

In 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 openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jul 27, 2026
@openshift-ci

openshift-ci Bot commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Hello @simonpasquier! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

@coderabbitai

coderabbitai Bot commented Jul 27, 2026

Copy link
Copy Markdown

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: 6e93f4ed-1621-4bf2-b2a5-af3b8f61281b

📥 Commits

Reviewing files that changed from the base of the PR and between f1d4a72 and bdca5d6.

⛔ Files ignored due to path filters (5)
  • config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1alpha1/zz_generated.featuregated-crd-manifests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml is excluded by !**/zz_generated.featuregated-crd-manifests/**
  • config/v1alpha1/zz_generated.swagger_doc_generated.go is excluded by !**/zz_generated*
  • openapi/generated_openapi/zz_generated.openapi.go is excluded by !openapi/**, !**/zz_generated*
  • openapi/openapi.json is excluded by !openapi/**
📒 Files selected for processing (2)
  • config/v1alpha1/types_cluster_monitoring.go
  • payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml
🚧 Files skipped from review as they are similar to previous changes (2)
  • config/v1alpha1/types_cluster_monitoring.go
  • payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml

📝 Walkthrough

Walkthrough

Adds an optional messageVersion field to RemoteWriteSpec, defines V1.0 and V2.0 enum values, and updates the ClusterMonitoring CRD schema to validate those values.

Suggested reviewers: joelspeed

🚥 Pre-merge checks | ✅ 14 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name Status Explanation Resolution
Description check ❓ Inconclusive No pull request description was provided, so there is no meaningful description to evaluate. Add a brief description of the change and its purpose so the PR context is clear.
✅ Passed checks (14 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly matches the main change: exposing the remote-write protocol version.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Stable And Deterministic Test Names ✅ Passed The only touched files are API/CRD schema files; no Ginkgo test declarations or *_test.go changes appear in the PR.
Test Structure And Quality ✅ Passed No Ginkgo test code was added or changed; this PR only updates API/CRD schema and declarative YAML fixtures, so the test-structure checks don’t apply.
Microshift Test Compatibility ✅ Passed PASS: The PR only adds API schema/types and generated manifests; no *_test.go files or Ginkgo test constructs were added, so MicroShift compatibility is unaffected.
Single Node Openshift (Sno) Test Compatibility ✅ Passed PR only adds RemoteWrite API/CRD fields; no new Ginkgo/e2e tests or SNO-sensitive node assumptions were introduced.
Topology-Aware Scheduling Compatibility ✅ Passed Only a remote-write messageVersion field/enum was added; no scheduling, affinity, toleration, or replica logic changed.
Ote Binary Stdout Contract ✅ Passed PR only changes API types, CRDs, and generated docs; no main/TestMain/Suite entrypoint code or stdout/logging writes were added.
Ipv6 And Disconnected Network Test Compatibility ✅ Passed PASS: PR adds only API/CRD and declarative YAML fixtures; no new Ginkgo e2e test code or external connectivity logic was introduced.
No-Weak-Crypto ✅ Passed The PR only adds a RemoteWrite messageVersion enum/field and CRD schema; no weak crypto, custom crypto, or secret/token comparisons appear.
Container-Privileges ✅ Passed Changed files only add remote-write messageVersion schema; no privileged, hostPID/hostNetwork/hostIPC, SYS_ADMIN, root, or allowPrivilegeEscalation settings appear.
No-Sensitive-Data-In-Logs ✅ Passed Only adds a RemoteWrite messageVersion field/type and CRD enum/docs; no logging statements or sensitive-data exposure were introduced.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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
The command is terminated due to an error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented


Comment @coderabbitai help to get the list of available commands.

@openshift-ci openshift-ci Bot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Jul 27, 2026
@qodo-for-rh-openshift

Copy link
Copy Markdown

PR Summary by Qodo

Expose remote-write protocol version in ClusterMonitoringConfig

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

Grey Divider

AI Description

• Add messageVersion to remoteWrite endpoints to select Remote Write v1.0 vs v2.0.
• Extend CRD validation with an enum and propagate it to generated CRD/OpenAPI artifacts.
• Update API documentation (Swagger/OpenAPI) to describe the new field and behavior.
Diagram

graph TD
  A["Cluster admin"] --> B["ClusterMonitoringConfig CRD"] --> C["remoteWrite.messageVersion"] --> D["Config generator"] --> E["Prometheus remote_write"] --> F["Remote storage endpoint"]
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Auto-negotiate/auto-detect protocol version
  • ➕ No new API surface for users to learn
  • ➕ Can evolve defaults without exposing protocol details
  • ➖ Remote Write does not have a universal negotiation mechanism
  • ➖ Harder to make behavior predictable for strict receivers
2. Boolean flag (e.g., useRemoteWriteV2)
  • ➕ Simpler user experience than a versioned enum
  • ➖ Does not scale for future versions (v3, etc.)
  • ➖ Less explicit and harder to validate/extend cleanly
3. Expose version via header-only configuration
  • ➕ Keeps payload versioning out of the CRD spec
  • ➕ Potentially aligns with intermediary proxies
  • ➖ Header-based signaling alone may not guarantee protobuf payload compatibility
  • ➖ More ambiguous than selecting the message type explicitly

Recommendation: The PR’s enum-based CRD field is the most future-proof and validation-friendly approach for selecting Remote Write message versions. Reviewers should mainly verify that the user-facing documentation strings match the actual enum values (V1.0/V2.0) and that downstream config rendering (outside this diff) consumes the field as intended.

Files changed (7) +61 / -0

Enhancement (1) +17 / -0
types_cluster_monitoring.goAdd remote-write message version field and enum type +17/-0

Add remote-write message version field and enum type

• Introduces 'RemoteWriteSpec.MessageVersion' to allow selecting the remote-write protocol message version per endpoint. Adds a 'RemoteWriteMessageVersion' string type with enum validation and constants for V1.0 and V2.0.

config/v1alpha1/types_cluster_monitoring.go

Documentation (2) +6 / -0
zz_generated.swagger_doc_generated.goDocument messageVersion in generated Swagger docs +1/-0

Document messageVersion in generated Swagger docs

• Adds the 'messageVersion' field description to the generated Swagger documentation map for 'RemoteWriteSpec'. Keeps the API docs in sync with the CRD/schema addition.

config/v1alpha1/zz_generated.swagger_doc_generated.go

openapi.jsonPublish messageVersion in JSON OpenAPI output +5/-0

Publish messageVersion in JSON OpenAPI output

• Updates the repository’s OpenAPI JSON to include the new 'messageVersion' property under 'RemoteWriteSpec'. Maintains parity between Go-generated schema and exported JSON.

openapi/openapi.json

Other (4) +38 / -0
0000_10_config-operator_01_clustermonitorings.crd.yamlRegenerate CRD schema to include messageVersion +10/-0

Regenerate CRD schema to include messageVersion

• Extends the ClusterMonitoringConfig CRD OpenAPI schema for remoteWrite entries with the 'messageVersion' field. Adds enum validation values V1.0 and V2.0 and includes the field description.

config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yaml

ClusterMonitoringConfig.yamlUpdate feature-gated CRD manifest with messageVersion +10/-0

Update feature-gated CRD manifest with messageVersion

• Propagates the 'messageVersion' field into the feature-gated CRD manifest variant. Ensures the same enum validation and description are present for remoteWrite items.

config/v1alpha1/zz_generated.featuregated-crd-manifests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml

zz_generated.openapi.goAdd messageVersion to generated Go OpenAPI schema +8/-0

Add messageVersion to generated Go OpenAPI schema

• Extends the generated OpenAPI schema for 'RemoteWriteSpec' with a 'messageVersion' string property and its description/default. Ensures programmatic OpenAPI consumers see the new field.

openapi/generated_openapi/zz_generated.openapi.go

0000_10_config-operator_01_clustermonitorings.crd.yamlUpdate payload CRD with messageVersion schema +10/-0

Update payload CRD with messageVersion schema

• Applies the same 'messageVersion' schema addition (description + enum V1.0/V2.0) to the payload CRD manifest used for delivery. Ensures cluster payload contains the updated CRD.

payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml

@openshift-ci
openshift-ci Bot requested review from JoelSpeed and everettraven July 27, 2026 14:54
@openshift-ci

openshift-ci Bot commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign joelspeed for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 967cc4c and fced126.

⛔ Files ignored due to path filters (5)
  • config/v1alpha1/zz_generated.crd-manifests/0000_10_config-operator_01_clustermonitorings.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • config/v1alpha1/zz_generated.featuregated-crd-manifests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml is excluded by !**/zz_generated.featuregated-crd-manifests/**
  • config/v1alpha1/zz_generated.swagger_doc_generated.go is excluded by !**/zz_generated*
  • openapi/generated_openapi/zz_generated.openapi.go is excluded by !openapi/**, !**/zz_generated*
  • openapi/openapi.json is excluded by !openapi/**
📒 Files selected for processing (2)
  • config/v1alpha1/types_cluster_monitoring.go
  • payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml

Comment thread config/v1alpha1/types_cluster_monitoring.go Outdated
Comment thread payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml Outdated
@qodo-for-rh-openshift

qodo-for-rh-openshift Bot commented Jul 27, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used
✅ Compliance rules (platform): 29 rules
✅ Skills: api-review

Grey Divider


Action required

1. messageVersion docs mismatch enum ✓ Resolved 📜 Skill insight ≡ Correctness
Description
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.
Code

config/v1alpha1/types_cluster_monitoring.go[R1553-1558]

+	// 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"`
Relevance

●●● Strong

Team often fixes API doc/schema inconsistencies; enum/doc mismatch would break users and is a simple
comment update.

PR-#2481
PR-#2645

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
PR Compliance ID 1509 forbids contradictions between field documentation and kubebuilder validation
constraints. In the cited code, the messageVersion field comment states the accepted values are
Version1.0/Version2.0, while the RemoteWriteMessageVersion type is constrained via
+kubebuilder:validation:Enum to V1.0/V2.0, meaning the generated CRD enum will only accept
V1.0 and V2.0; therefore the documented values will fail API-server/CRD schema validation and
mislead users and tooling.

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]
Skill: api-review

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## 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


Grey Divider

To customize comments, go to the Qodo configuration screen, or learn more in the docs.

Qodo Logo

Comment thread config/v1alpha1/types_cluster_monitoring.go Outdated
Comment on lines +1555 to +1556
// 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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the current default behavior?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should document what the current default behavior is.

Signed-off-by: Simon Pasquier <spasquie@redhat.com>
@openshift-ci

openshift-ci Bot commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

@simonpasquier: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/verify-hypershift-integration bdca5d6 link true /test verify-hypershift-integration

Full PR test history. Your PR dashboard.

Details

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 kubernetes-sigs/prow repository. I understand the commands that are listed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants