Skip to content

Conversation

@machadovilaca
Copy link
Owner

@machadovilaca machadovilaca commented Dec 4, 2025

This PR refactors how platform managed alert rules are identified in management API and Kubernetes client. It removes hard-coded namespace naming assumptionson platform namespace, and now relies on informers for to check the cluster monitoring label on the namespaces

https://issues.redhat.com/browse/CNV-71645

return ni, err
}

func namespaceListWatch(client corev1client.CoreV1Interface) *cache.ListWatch {
Copy link
Collaborator

Choose a reason for hiding this comment

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

maybe set a LabelSelector for openshift.io/cluster-monitoring=true to reduce watch/list volume

Copy link
Owner Author

Choose a reason for hiding this comment

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

nice catch, thought i added it, but forgot

)

const (
// ClusterMonitoringLabel is the label used to identify namespaces with cluster monitoring enabled
Copy link
Collaborator

Choose a reason for hiding this comment

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

This label is used to define Platform alerts.
Alerts defined in a PrometheusRule in a namespace that has this label will be evaluated by the platform stack.

@sradco
Copy link
Collaborator

sradco commented Dec 9, 2025

This PR refactors how platform managed alert rules are identified in management API and Kubernetes client. It removes hard-coded namespace naming assumptionson platform namespace, and now relies on informers for to check the cluster monitoring label on the namespaces

https://issues.redhat.com/browse/CNV-71645

@machadovilaca This should say that we set the source label as platform for alerts if the namespace of the Prometheus of the alert has the openshift.io/cluster-monitoring: true label.

For User alerts we should check if there is an ownerrefence annotation set for the Prometheus rule, if yes we should add another labels to be able to report how it is managed. Can be in a separate PR or commit.

@machadovilaca machadovilaca force-pushed the change-IsPlatformAlertRule-implementation branch from 2e122a4 to 24f4d76 Compare December 9, 2025 13:51
@machadovilaca
Copy link
Owner Author

This PR refactors how platform managed alert rules are identified in management API and Kubernetes client. It removes hard-coded namespace naming assumptionson platform namespace, and now relies on informers for to check the cluster monitoring label on the namespaces
https://issues.redhat.com/browse/CNV-71645

@machadovilaca This should say that we set the source label as platform for alerts if the namespace of the Prometheus of the alert has the openshift.io/cluster-monitoring: true label.

For User alerts we should check if there is an ownerrefence annotation set for the Prometheus rule, if yes we should add another labels to be able to report how it is managed. Can be in a separate PR or commit.

not yet, next PR
we are just changing the approach here
that info is still not added to the results

}
ni.updateMonitoringNamespace(ns)
},
DeleteFunc: func(obj interface{}) {
Copy link
Collaborator

@avlitman avlitman Dec 9, 2025

Choose a reason for hiding this comment

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

consider checking also obj.(cache.DeletedFinalStateUnknown) in case of fast create and delete

Copy link
Owner Author

Choose a reason for hiding this comment

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

done

Signed-off-by: machadovilaca <machadovilaca@gmail.com>
@machadovilaca machadovilaca force-pushed the change-IsPlatformAlertRule-implementation branch from 24f4d76 to 3c503cb Compare December 9, 2025 15:25
@machadovilaca machadovilaca merged commit fb8a751 into add-alert-management-api-base Dec 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants