MON-4565: Add enableUserAlertmanagerConfig to ClusterMonitoring API#2855
MON-4565: Add enableUserAlertmanagerConfig to ClusterMonitoring API#2855marioferh wants to merge 2 commits into
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
openshift-ci-robot
added
the
jira/valid-reference
|
@marioferh: This pull request references MON-4565 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 story 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. |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR adds a UserAlertmanagerConfigSelection enum (Selectable, None) and an optional userAlertmanagerConfigSelection field on AlertmanagerCustomConfig, updates the ClusterMonitoring CRD to include the enum property and documentation, and adds creation tests: one verifying a Selectable value is preserved in generated manifests and one verifying an unsupported value (Enabled) is rejected with the expected validation error. Suggested reviewers
🚥 Pre-merge checks | ✅ 14 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (14 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
|
Hello @marioferh! Some important instructions when contributing to openshift/api: |
openshift-ci
Bot
added
the
size/L
marioferh
force-pushed
the
alertmanager_enableUserAlertmanagerConfig
branch
from
cbaa523 to
5c694c6
Compare
![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/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml`:
- Around line 21-39: Add a parallel test case for the other enum value by
duplicating the existing test named "Should accept
userAlertmanagerConfigSelection on alertmanagerConfig" and change the
alertmanagerConfig.userAlertmanagerConfigSelection value to "None" in both the
initial and expected YAML blocks; ensure the new test name reflects the change
(e.g., "Should accept userAlertmanagerConfigSelection None value on
alertmanagerConfig") and that the key userAlertmanagerConfigSelection appears
exactly as in the original so the test validates preservation of the "None"
enum.
- Around line 21-50: Add a new test case that verifies alertmanagerConfig can be
created without the optional field userAlertmanagerConfigSelection by adding an
entry named "Should accept alertmanagerConfig without
userAlertmanagerConfigSelection" that provides an initial ClusterMonitoring with
spec.alertmanagerConfig containing only deploymentMode: "DefaultConfig" and
expects the same object back; ensure you reference the alertmanagerConfig object
and the userAlertmanagerConfigSelection symbol so the test confirms omission is
accepted and defaults are handled.
🪄 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: bb30ad99-c017-46cc-b23f-ec272ba53b23
⛔ 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 (3)
config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yamlconfig/v1alpha1/types_cluster_monitoring.gopayload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml
| - name: Should accept userAlertmanagerConfigSelection on alertmanagerConfig | ||
| initial: | | ||
| apiVersion: config.openshift.io/v1alpha1 | ||
| kind: ClusterMonitoring | ||
| spec: | ||
| userDefined: | ||
| mode: "Disabled" | ||
| alertmanagerConfig: | ||
| deploymentMode: "DefaultConfig" | ||
| userAlertmanagerConfigSelection: Selectable | ||
| expected: | | ||
| apiVersion: config.openshift.io/v1alpha1 | ||
| kind: ClusterMonitoring | ||
| spec: | ||
| userDefined: | ||
| mode: "Disabled" | ||
| alertmanagerConfig: | ||
| deploymentMode: "DefaultConfig" | ||
| userAlertmanagerConfigSelection: Selectable |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win
Add test coverage for the "None" enum value.
The validation error on line 50 indicates that userAlertmanagerConfigSelection supports two values: "Selectable" and "None". Currently only "Selectable" is tested for acceptance. Add a similar test case that verifies "None" is also accepted and preserved.
📋 Proposed additional test case
- name: Should accept userAlertmanagerConfigSelection None value on alertmanagerConfig
initial: |
apiVersion: config.openshift.io/v1alpha1
kind: ClusterMonitoring
spec:
userDefined:
mode: "Disabled"
alertmanagerConfig:
deploymentMode: "DefaultConfig"
userAlertmanagerConfigSelection: None
expected: |
apiVersion: config.openshift.io/v1alpha1
kind: ClusterMonitoring
spec:
userDefined:
mode: "Disabled"
alertmanagerConfig:
deploymentMode: "DefaultConfig"
userAlertmanagerConfigSelection: None🤖 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/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml`
around lines 21 - 39, Add a parallel test case for the other enum value by
duplicating the existing test named "Should accept
userAlertmanagerConfigSelection on alertmanagerConfig" and change the
alertmanagerConfig.userAlertmanagerConfigSelection value to "None" in both the
initial and expected YAML blocks; ensure the new test name reflects the change
(e.g., "Should accept userAlertmanagerConfigSelection None value on
alertmanagerConfig") and that the key userAlertmanagerConfigSelection appears
exactly as in the original so the test validates preservation of the "None"
enum.
| - name: Should accept userAlertmanagerConfigSelection on alertmanagerConfig | ||
| initial: | | ||
| apiVersion: config.openshift.io/v1alpha1 | ||
| kind: ClusterMonitoring | ||
| spec: | ||
| userDefined: | ||
| mode: "Disabled" | ||
| alertmanagerConfig: | ||
| deploymentMode: "DefaultConfig" | ||
| userAlertmanagerConfigSelection: Selectable | ||
| expected: | | ||
| apiVersion: config.openshift.io/v1alpha1 | ||
| kind: ClusterMonitoring | ||
| spec: | ||
| userDefined: | ||
| mode: "Disabled" | ||
| alertmanagerConfig: | ||
| deploymentMode: "DefaultConfig" | ||
| userAlertmanagerConfigSelection: Selectable | ||
| - name: Should reject invalid userAlertmanagerConfigSelection on alertmanagerConfig | ||
| initial: | | ||
| apiVersion: config.openshift.io/v1alpha1 | ||
| kind: ClusterMonitoring | ||
| spec: | ||
| userDefined: | ||
| mode: "Disabled" | ||
| alertmanagerConfig: | ||
| deploymentMode: "DefaultConfig" | ||
| userAlertmanagerConfigSelection: Enabled | ||
| expectedError: 'spec.alertmanagerConfig.userAlertmanagerConfigSelection: Unsupported value: "Enabled": supported values: "Selectable", "None"' |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major | ⚡ Quick win
Add test coverage for optional field behavior.
Per the PR summary and AI-generated description, userAlertmanagerConfigSelection is an optional field. Add a test case that explicitly verifies an alertmanagerConfig object can be created without this field, confirming the optional behavior and default handling.
📋 Proposed additional test case
- name: Should accept alertmanagerConfig without userAlertmanagerConfigSelection
initial: |
apiVersion: config.openshift.io/v1alpha1
kind: ClusterMonitoring
spec:
userDefined:
mode: "Disabled"
alertmanagerConfig:
deploymentMode: "DefaultConfig"
expected: |
apiVersion: config.openshift.io/v1alpha1
kind: ClusterMonitoring
spec:
userDefined:
mode: "Disabled"
alertmanagerConfig:
deploymentMode: "DefaultConfig"🤖 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/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml`
around lines 21 - 50, Add a new test case that verifies alertmanagerConfig can
be created without the optional field userAlertmanagerConfigSelection by adding
an entry named "Should accept alertmanagerConfig without
userAlertmanagerConfigSelection" that provides an initial ClusterMonitoring with
spec.alertmanagerConfig containing only deploymentMode: "DefaultConfig" and
expects the same object back; ensure you reference the alertmanagerConfig object
and the userAlertmanagerConfigSelection symbol so the test confirms omission is
accepted and defaults are handled.
| // When omitted, the default value is None. | ||
| // +optional | ||
| // +kubebuilder:validation:Enum=Selectable;None | ||
| UserAlertmanagerConfigSelection UserAlertmanagerConfigSelection `json:"userAlertmanagerConfigSelection,omitempty"` |
There was a problem hiding this comment.
should this be moved to AlertmanagerCustomConfig instead?
There was a problem hiding this comment.
This seems reasonable to me.
There was a problem hiding this comment.
done, but not sure if this is the best option as this only applies when deploymentMode is CustomConfig, unlike the ConfigMap where enableUserAlertmanagerConfig: true can be set with otherwise default Alertmanager settings. CMO merge will need to map customConfig.userAlertmanagerConfigSelection: Selectable to the existing internal flag.
There was a problem hiding this comment.
For the migration, I expect that we always "convert" to CustomConfig deployment.
| // When set to Selectable, the platform Alertmanager discovers AlertmanagerConfig resources | ||
| // in user-defined namespaces. This is equivalent to `enableUserAlertmanagerConfig: true` in | ||
| // the cluster-monitoring-config ConfigMap. |
There was a problem hiding this comment.
How are these resources discovered? Is there any additional configuration options we may want to support for how these are discovered?
There was a problem hiding this comment.
The (Prometheus) operator discovers all AlertmanagerConfig resources in all namespaces which are not labelled with openshift.io/cluster-monitoring: true (aka user namespaces).
There was a problem hiding this comment.
Is there any chance we would like to allow customers to have more fine grained control over what AlertmanagerConfig resources are discovered? For example, specifying label selectors?
marioferh
force-pushed
the
alertmanager_enableUserAlertmanagerConfig
branch
from
5c694c6 to
4d42991
Compare
| // on the platform Alertmanager. This is equivalent to `enableUserAlertmanagerConfig: false` | ||
| // in the cluster-monitoring-config ConfigMap. | ||
| // This setting only applies when the user-workload monitoring Alertmanager is not enabled. | ||
| // When omitted, the default value is None. |
There was a problem hiding this comment.
Should this follow the typical "no opinion" pattern?
marioferh
force-pushed
the
alertmanager_enableUserAlertmanagerConfig
branch
from
4d42991 to
842840a
Compare
openshift-ci
Bot
added
the
needs-rebase
|
Actionable comments posted: 0 |
Restore parity with the cluster-monitoring-config ConfigMap field enableUserAlertmanagerConfig that was removed from AlertmanagerConfig during API review (openshift#2148). userAlertmanagerConfigSelection uses Selectable and None enum values (kube-api-linter nobools) instead of a boolean: Selectable matches enableUserAlertmanagerConfig: true, None matches false. The platform Alertmanager in openshift-monitoring discovers AlertmanagerConfig resources in user-defined namespaces only when set to Selectable and user-workload Alertmanager is not enabled. Omitted defaults to None. Includes CRD/OpenAPI codegen and integration tests. Co-authored-by: Cursor <cursoragent@cursor.com>
marioferh
force-pushed
the
alertmanager_enableUserAlertmanagerConfig
branch
from
842840a to
f0985da
Compare
Address API review feedback to colocate user-namespace AlertmanagerConfig lookup settings with other Alertmanager deployment options in AlertmanagerCustomConfig. The field is only valid when deploymentMode is CustomConfig, matching the customConfig union semantics. Update integration tests and regenerated CRD/OpenAPI artifacts. Co-authored-by: Cursor <cursoragent@cursor.com>
marioferh
force-pushed
the
alertmanager_enableUserAlertmanagerConfig
branch
from
f0985da to
f9a89e1
Compare
openshift-ci
Bot
removed
the
needs-rebase
There was a problem hiding this comment.
🧹 Nitpick comments (1)
config/v1alpha1/types_cluster_monitoring.go (1)
799-811: 💤 Low valueConsider adding enum validation marker on the type for consistency.
Other enums in this file (e.g.,
LogLevel,AlertManagerDeployMode,RequestLoggingPolicy,CrossOriginRequestPolicy) define+kubebuilder:validation:Enumon the type itself, whileUserAlertmanagerConfigSelectionrelies on field-level validation at line 834. Both approaches work functionally, but type-level validation is more consistent with the file's patterns and ensures validation is applied if the type is reused elsewhere.Suggested change for consistency
// UserAlertmanagerConfigSelection controls whether the platform Alertmanager selects // AlertmanagerConfig resources from user-defined namespaces. +// +kubebuilder:validation:Enum=Selectable;None // +enum type UserAlertmanagerConfigSelection string🤖 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 799 - 811, Add a type-level kubebuilder enum validation marker to UserAlertmanagerConfigSelection so validation is consistent with other enums; update the type declaration for UserAlertmanagerConfigSelection to include a +kubebuilder:validation:Enum=<values> marker listing "Selectable" and "None" (matching the constants UserAlertmanagerConfigSelectionSelectable and UserAlertmanagerConfigSelectionNone) so the enum validation is applied whenever the type is reused.
🤖 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.
Nitpick comments:
In `@config/v1alpha1/types_cluster_monitoring.go`:
- Around line 799-811: Add a type-level kubebuilder enum validation marker to
UserAlertmanagerConfigSelection so validation is consistent with other enums;
update the type declaration for UserAlertmanagerConfigSelection to include a
+kubebuilder:validation:Enum=<values> marker listing "Selectable" and "None"
(matching the constants UserAlertmanagerConfigSelectionSelectable and
UserAlertmanagerConfigSelectionNone) so the enum validation is applied whenever
the type is reused.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 46d31d87-09d1-4c13-9b36-546e2925f526
⛔ 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 (3)
config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yamlconfig/v1alpha1/types_cluster_monitoring.gopayload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml
🚧 Files skipped from review as they are similar to previous changes (2)
- config/v1alpha1/tests/clustermonitorings.config.openshift.io/ClusterMonitoringConfig.yaml
- payload-manifests/crds/0000_10_config-operator_01_clustermonitorings.crd.yaml
|
Scheduling tests matching the |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: everettraven The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
|
@marioferh: all tests passed! 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. |
5 participants
Restore parity with the cluster-monitoring-config ConfigMap field that was removed from AlertmanagerConfig during API review (#2148). When true, the platform Alertmanager in openshift-monitoring discovers AlertmanagerConfig resources in user-defined namespaces; this only applies when user-workload Alertmanager is not enabled. Omitted means false, matching the ConfigMap default.
Includes CRD/OpenAPI codegen and an integration test for the new field.