MON-4620: expose remote-write protocol version

[simonpasquier]

No description provided.

[openshift-merge-bot]

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]

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

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]

Note

Currently processing new changes in this PR. This may take a few minutes, please wait...

⚙️ Run configuration

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

Review profile: CHILL

Plan: Enterprise

Run ID: e94b4a6c-73af-455d-9e83-a4aa6d3e831f

📥 Commits

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

⛔ 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

📝 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

---

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

[qodo-for-rh-openshift]

PR Summary by Qodo

Expose remote-write protocol version in ClusterMonitoringConfig

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

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]

[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:

• OWNERS

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

[coderabbitai]

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

[qodo-for-rh-openshift]

Code Review by Qodo

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

Context used

✅ Compliance rules (platform): 29 rules

✅ Skills: api-review

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

---

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

[everettraven]

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.

[everettraven]

What is the current default behavior?

[everettraven]

We should document what the current default behavior is.

[simonpasquier]

Thanks, the documentation now mentions that The default value is "V1.0".

[openshift-ci]

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