MON-4609 - Add configurationSource selector to ClusterMonitoring API.

[marioferh]

Allow choosing between the cluster-monitoring-config ConfigMap and the ClusterMonitoring CRD as the configuration source, defaulting to CRD.

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

Hello @marioferh! 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]

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: 652cc5c9-e3b0-4abb-ad9e-fbe641bc3f2c

📥 Commits

Reviewing files that changed from the base of the PR and between 96752c7 and 37cb690.

📒 Files selected for processing (1)

• config/v1alpha1/types_cluster_monitoring.go

💤 Files with no reviewable changes (1)

• config/v1alpha1/types_cluster_monitoring.go

---

📝 Walkthrough

Walkthrough

Adds an optional spec.configurationSource field to ClusterMonitoringSpec with ConfigMap and CRD enum values. Updates the ClusterMonitoring CRD schema with the field and default behavior, and adds validation tests for supported values and rejection of Invalid.

Suggested reviewers: joelspeed, everettraven

🚥 Pre-merge checks | ✅ 15

✅ Passed checks (15 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly states the main API change by adding the configurationSource selector to ClusterMonitoring.
Description check	✅ Passed	The description matches the change by explaining the selectable config source and the CRD default.
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 added test titles are static, descriptive strings with no dynamic suffixes, timestamps, UUIDs, or other run-specific values.
Test Structure And Quality	✅ Passed	The added YAML validation cases are isolated, one behavior per test, and match existing schema-test patterns; no cluster ops, waits, or cleanup gaps.
Microshift Test Compatibility	✅ Passed	Added tests are envtest YAML validation cases, not Ginkgo e2e specs, and no MicroShift-specific unsupported API usage was introduced.
Single Node Openshift (Sno) Test Compatibility	✅ Passed	Added tests only validate ClusterMonitoring CRD schema values/errors; they don’t schedule pods, inspect topology, or assume multi-node behavior.
Topology-Aware Scheduling Compatibility	✅ Passed	PR only adds configurationSource API/CRD validation and tests; no deployment manifests, controllers, node selectors, affinity, or replica logic changed.
Ote Binary Stdout Contract	✅ Passed	PR only changes API/CRD/schema files; no main/init/TestMain/BeforeSuite code or stdout logging/prints appear in changed files.
Ipv6 And Disconnected Network Test Compatibility	✅ Passed	No new Ginkgo e2e tests were added; the new ClusterMonitoring YAML validation cases only set configurationSource and contain no IPv4 or external connectivity assumptions.
No-Weak-Crypto	✅ Passed	Touched files only add configurationSource schema/tests; exact scans found no MD5/SHA1/DES/RC4/3DES/Blowfish/ECB or constant-time compare usage.
Container-Privileges	✅ Passed	Changed files are API/CRD/tests only; none contain privileged, host* namespace, SYS_ADMIN, root, or allowPrivilegeEscalation settings.
No-Sensitive-Data-In-Logs	✅ Passed	The PR only adds API schema/tests; I found no new logging statements or sensitive-data outputs in the touched files.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

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

[openshift-ci]

@marioferh: 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	37cb690	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.

[JoelSpeed]

/test api-review

[qodo-for-rh-openshift]

PR-Agent: could not find a component named api-review in a supported language in this PR.

[openshift-api-review-bot]

I've reviewed all the changes in this diff. Let me verify my analysis is complete by checking the new field and type against all 7 rules:

New configurationSource field (line 79-89 in the new file):

1. Field Documentation: Present. The comment thoroughly describes the field's purpose.
2. Optional Field Behavior: +optional is present, and the comment explains: "When omitted, this means no opinion and the platform is left to choose a reasonable default, which is subject to change over time. The current default value is CRD."
3. Validation Documentation: The Enum=ConfigMap;CRD constraint is on the ConfigurationSource type. The field's own comment lists both valid values ("Valid values are 'ConfigMap' and 'CRD'") and explains each ("When set to ConfigMap, ...", "When set to CRD, ...").
4. Validation / Documentation Mismatch: No contradictions found.
5. Missing Cross-field Validation: No cross-field relationships documented.
6. Undocumented Constraints: The only constraint is the Enum on the type, which is documented in the field comment.
7. CEL Expression Review: No CEL expressions added.

New ConfigurationSource type (lines 771-783): This is a type definition with +kubebuilder:validation:Enum=ConfigMap;CRD and +enum, with properly documented constants. The field using this type documents the enum values in its own comment.

No issues found. The new configurationSource field and ConfigurationSource type are well-documented: the field comment explains optionality/omission behavior, lists all valid enum values with their meanings, and has no validation/documentation mismatches. The swagger doc generated file is consistent with the field comment.

---

Run locally: claude -p "/api-review" from a clone of this PR.
Iterate locally before pushing — it's faster and doesn't use CI budget.

Job artifacts | Report a problem

[everettraven]

It's been a little while since I've reviewed something on this API - could you remind me who is intended to create this resource initially?

Is it an end-user that creates an instance of this resource or will this follow a similar pattern to other config resources where the platform ships with a default instance of this resource named cluster?