You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Incident detection feature reaches General Availability::
41
+
The incident detection feature in the {coo-full} reaches General Availability (GA) status in this release. Incident detection simplifies observability by grouping related alerts into incidents. This helps reduce alert fatigue and allows you to focus on the root cause of a problem. With General Availability (GA) status, the incident detection feature is production-ready and fully supported for enterprise deployments. Users can enable incident detection through the monitoring `UIPlugin` resource by setting `spec.monitoring.incidents.enabled: true`.
42
+
+
43
+
For more information, see xref:../ui_plugins/monitoring-ui-plugin.adoc#coo-incident-detection-overview_monitoring-ui-plugin[Incident detection]
The incidents view in the monitoring UI plugin supports silenced alerts in this release. Silenced alerts display with a `state` of `Silenced` in the incident detection UI and appear in a lighter color in the timeline. This helps you to distinguish them from active alerts and to understand the complete state of your cluster observability signals.
End-to-end observability with ClusterObservability custom resource::
54
+
The {coo-full} provides a `ClusterObservability` custom resource for deploying end-to-end observability with minimal configuration as a Technology Preview feature. The `ClusterObservability` custom resource simplifies the deployment of logging, tracing, and OpenTelemetry capabilities by automatically managing operator installation, storage configuration, and UI integration.
Before this update, {product-title} 4.19 introduced changes to alert URL formatting where some URLs contained only console-internal numeric IDs without alert names. As a consequence, the korrel8r troubleshooting panel failed to process these URLs correctly and could not correlate alerts with related resources.
61
+
+
62
+
With this release, korrel8r correctly handles alert URLs from {product-title} 4.19, including URLs that contain only numeric identifiers. As a result, the troubleshooting panel works correctly with all alert types on {product-title} 4.19 clusters.
Troubleshooting panel generates valid LogQL queries for Loki logs::
68
+
Before this update, the troubleshooting panel generated malformed LogQL queries when accessing Loki logs through the korrel8r graph. The panel omitted label names from query expressions, producing invalid syntax such as `{ :"value" }` instead of `{label="value"}`. As a consequence, users could not open Loki logs from the korrel8r graph in the {product-title} console and encountered parsing errors from the Observatorium API.
69
+
+
70
+
With this release, the troubleshooting panel correctly generates valid LogQL queries with proper label matcher syntax. As a result, users can successfully navigate from the korrel8r graph to corresponding Loki logs for detailed investigation.
`UIPlugin` monitoring configuration persists after operator upgrades::
76
+
Before this update, when upgrading the {coo-full} from version 1.2.0 to 1.2.1 or later, the monitoring `UIPlugin` configuration was removed during the upgrade process. The `UIPlugin` spec became empty, showing only the plugin type while losing all configuration details such as {rh-rhacm} integration settings, Perses dashboards, and incident management settings. As a consequence, users could not access monitoring dashboards and features after the upgrade, and the operator logged errors stating `monitoring configuration can not be empty for plugin type Monitoring`.
77
+
+
78
+
With this release, the {coo-full} correctly preserves monitoring `UIPlugin` configuration during upgrades. As a result, monitoring dashboards, {rh-rhacm} integration, and incident management features remain available after operator upgrades without requiring manual reconfiguration.
Before this update, the {coo-full} failed to reconcile `ServiceMonitor` resources due to a schema incompatibility in the Prometheus Operator client library. The client library did not properly declare the status field in the `ServiceMonitor` schema, causing patch operations to fail. As a consequence, the operator could not create or update `ServiceMonitor` resources and logged continuous reconciliation errors stating `updater failed to patch: failed to create typed patch object: .status: field not declared in schema`.
85
+
+
86
+
With this release, the {coo-full} uses an updated version of the Prometheus Operator client library that correctly declares the `ServiceMonitor` schema. As a result, `ServiceMonitor` resources reconcile successfully without errors.
Before this update, the troubleshooting panel did not sanitize Kubernetes label names when translating pod queries to Loki log queries. The panel generated Loki queries with invalid label names containing characters that Loki does not accept, such as dots and hyphens. As a consequence, users encountered "invalid query" errors when accessing logs from the troubleshooting panel correlation graph for pods with certain label names.
94
+
+
95
+
With this release, the {coo-full} troubleshooting panel correctly sanitizes Kubernetes label names by replacing invalid characters with underscores when generating Loki queries. As a result, users can successfully access logs from the correlation graph for all pods regardless of their label names.
Troubleshooting panel navigates to Kubernetes Events page::
102
+
Before this update, clicking on Kubernetes Events in the troubleshooting panel visualization node failed to navigate to the Events page in the {product-title} console. As a consequence, users could not view detailed Kubernetes Event information through the troubleshooting panel workflow and had to manually navigate to the Events page.
103
+
+
104
+
With this release, the troubleshooting panel correctly handles navigation to the Kubernetes Events page when users click on event nodes in the visualization. As a result, users can successfully navigate from the troubleshooting panel to view detailed Kubernetes Event information in the console.
Troubleshooting panel navigates to VirtualMachine resources correctly::
111
+
Before this update, the troubleshooting panel generated incorrect URLs when navigating to `VirtualMachineInstance` resources from the visualization graph. The panel used an invalid resource path format that did not exist in the {product-title} console. As a consequence, users received 404 errors when clicking on `VirtualMachineInstance` nodes in the troubleshooting panel and could not view virtual machine details.
112
+
+
113
+
With this release, the troubleshooting panel generates correct URLs using the proper API group format (`kubevirt.io~v1~VirtualMachine`) when navigating to virtual machine resources. As a result, users can successfully navigate from the troubleshooting panel to view `VirtualMachine` resource details in the console.
Before this update, the korrel8r binary was not compiled with Federal Information Processing Standards (FIPS) compliant mode enabled. As a consequence, korrel8r pods failed to start on FIPS-enabled clusters and logged the error "FIPS mode is enabled, but this binary is not compiled with FIPS compliant mode enabled."
120
+
+
121
+
With this release, the korrel8r container image uses a FIPS-compliant base image and the binary is compiled with FIPS mode enabled. As a result, korrel8r runs successfully on FIPS-enabled {product-title} clusters.
`UIPlugin` status updates correctly in all reconciliation scenarios::
126
+
Before this update, the `UIPlugin` controller did not update the custom resource status field in all reconciliation scenarios. The controller failed to update the status when reconciliation errors occurred, causing the status to report success even when configuration changes were not applied. As a consequence, users could not accurately determine the state of `UIPlugin` resources through the status field and had to check the generation field or operator logs to debug issues.
127
+
+
128
+
With this release, the {coo-full} correctly updates `UIPlugin` status in all reconciliation scenarios, including error conditions. As a result, users can rely on the `UIPlugin` status field to accurately reflect the current state of the resource and troubleshoot configuration issues more effectively.
Distributed tracing `UIPlugin` handles double quotes in TraceQL queries::
133
+
Before this update, the distributed tracing `UIPlugin` in COO 1.2.2 did not properly handle double quotes in TraceQL query expressions. The query parser failed when attribute values contained double quotes, such as regex patterns in HTTP route attributes. As a consequence, users could not query traces with attributes containing double quotes, even when these values were selected from dropdown menus in the user interface.
134
+
+
135
+
With this release, the {product-title} distributed tracing console plugin correctly processes TraceQL queries containing double quotes in attribute values. As a result, users can query traces with any attribute values, including those containing special characters like double quotes.
Logging view plugin proxies to korrel8r only when troubleshooting panel is deployed::
140
+
Before this update, the logging view plugin in COO 1.2.1 configured the {product-title} console to proxy traffic to the korrel8r service even when the troubleshooting panel `UIPlugin` was not deployed. The console attempted to connect to a non-existent service, causing permission denied errors. As a consequence, users experienced transient "Missing permissions to get logs" error messages in the logging view, which resolved on their own after 30-60 seconds without user intervention.
141
+
+
142
+
With this release, the {coo-full} only configures the korrel8r proxy in the logging view plugin when the troubleshooting panel `UIPlugin` is deployed. As a result, users no longer encounter spurious permission errors when viewing logs without the troubleshooting panel.
Must-gather container image includes `jq` utility::
147
+
Before this update, the {coo-full} must-gather container image did not include the `jq` command-line JSON processor utility. As a consequence, users encountered "jq: command not found" errors when running `oc adm must-gather` to collect diagnostic data, though the must-gather process completed and collected other information.
148
+
+
149
+
With this release, the {coo-full} must-gather container image includes the `jq` utility. As a result, users can run must-gather without encountering errors, and the gather script can properly process JSON data from Prometheus and Alertmanager.
Distributed tracing search field supports keyboard navigation::
154
+
Before this update, the distributed tracing console plugin search field did not support keyboard-only navigation. When users typed a filter value and pressed `Enter` to select it, the page reset to the tenant selection screen instead of applying the filter. As a consequence, keyboard-only users could not filter traces by service name or other attributes and were forced to use mouse-based selection.
155
+
+
156
+
With this release, the {product-title} distributed tracing console plugin correctly handles the `Enter` key in search fields. As a result, users can apply trace filters using keyboard-only navigation, improving accessibility.
Before this update, the `UIPlugin` controller in COO 1.2.1 did not remove pods for disabled features when users updated the configuration. When users set `perses.enabled: false` or `incidents.enabled: false` in the `UIPlugin` specification, the associated pods (perses-0 and health-analyzer) continued to run. As a consequence, users could not disable Perses dashboards or incidents features, and the disabled components continued consuming cluster resources.
163
+
+
164
+
With this release, the {coo-full} correctly removes pods when features are disabled in the `UIPlugin` configuration. As a result, users can enable or disable Perses and incidents features by updating the `UIPlugin` specification, and the associated pods are created or removed accordingly.
* Previously, the logging UIPlugin was not in the `Available` state and the logging pod was not created, when installed on a specific version of {ocp-product-title}.
476
+
* Previously, the logging `UIPlugin` was not in the `Available` state and the logging pod was not created, when installed on a specific version of {ocp-product-title}.
327
477
This release resolves the issue. (link:https://issues.redhat.com/browse/COO-260[*COO-260*])
0 commit comments