gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: {product-title} console integration offers overview, topology view, and traffic flow tables in both *Administrator* and *Developer* perspectives.

In the *Administrator* perspective, you can find the Network Observability *Overview*, *Traffic flows*, and *Topology* views by clicking *Observe* -> *Network Traffic*. In the *Developer* perspective, you can view this information by clicking *Observe*. The Network Observability metrics dashboards in *Observe* -> *Dashboards* are only available to administrators.
Revised: {product-title} console integration offers an overview, a topology view, and traffic flow tables. The Network Observability metrics dashboards in *Observe* -> *Dashboards* are available only to users with administrator access.
Original: {product-title} console integration offers overview, topology view, and traffic flow tables in both *Administrator* and *Developer* perspectives.

In the *Administrator* perspective, you can find the Network Observability *Overview*, *Traffic flows*, and *Topology* views by clicking *Observe* -> *Network Traffic*. In the *Developer* perspective, you can view this information by clicking *Observe*. The Network Observability metrics dashboards in *Observe* -> *Dashboards* are only available to administrators.
To enable multi-tenancy for the developer perspective and for administrators with limited access to namespaces, you must specify permissions by defining roles. For more information, see xref:../../observability/network_observability/installing-operators.adoc#network-observability-multi-tenancy_network_observability[Enabling multi-tenancy in Network Observability].
Revised: To enable multi-tenancy for developer access and for administrators with limited access to namespaces, you must specify permissions by defining roles. For more information, see xref:../../observability/network_observability/installing-operators.adoc#network-observability-multi-tenancy_network_observability[Enabling multi-tenancy in Network Observability].
Original: spec:
storage: # <3>
backend: <supported_storage_type> # <4>
size: <value>Gi # <5>
s3: # <6>
secret: <secret_name> # <7>
tls: # <8>
caName: <ca_certificate_configmap_name> # <9>
enabled: true # <10>
enabled: true # <11>
resources: # <12>
authentication: # <13>
- tenantName: dev # <14>
tenantId: "1610b0c3-c509-4592-a256-a1871353dbfa" # <15>
<3> Specifies the storage for storing traces.
<4> Type of storage for storing traces: in-memory storage, a persistent volume, or object storage. The value for a persistent volume is `pv`. The accepted values for object storage are `s3`, `gcs`, or `azure`, depending on the used object store type. The default value is `memory` for the `tmpfs` in-memory storage, which is only appropriate for development, testing, demonstrations, and proof-of-concept environments because the data does not persist when the pod is shut down.
<5> Memory size: For in-memory storage, this means the size of the `tmpfs` volume, where the default is `2Gi`. For a persistent volume, this means the size of the persistent volume claim, where the default is `10Gi`. For object storage, this means the size of the persistent volume claim for the Tempo Write-Ahead Logging (WAL), where the default is `10Gi`.
<6> Optional: For object storage, the type of object storage. The accepted values are `s3`, `gcs`, and `azure`, depending on the used object store type.
<7> Optional: For object storage, the value of the `name` in the `metadata` of the storage secret. The storage secret must be in the same namespace as the TempoMonolithic instance and contain the fields specified in "Table 1. Required secret parameters" in the section "Object storage setup".
<8> Optional.
<9> Optional: Name of a `ConfigMap` object that contains a CA certificate.
<10> Exposes the Jaeger UI, which visualizes the data, via a route.
<11> Enables creation of a route for the Jaeger UI.
<12> Optional.
<13> Lists the tenants.
<14> The tenant name from the `X-Scope-OrgId` header when ingesting the data.
<15> The unique identifier of the tenant. Must be unique throughout the lifecycle of the TempoMonolithic deployment. This ID will be added as a prefix to the objects in the object storage. You can reuse the value of the UUID or `tempoName` field.
Revised: <3> Red{nbsp}Hat supports only the custom resource options that are available in the {DTProductName} documentation.
Original: <3> Specifies the storage for storing traces.
<4> The secret you created in step 2 for the object storage that had been set up as one of the prerequisites.
<5> The value of the `name` field in the `metadata` section of the secret. For example: `minio`.
<6> The accepted values are `azure` for Azure Blob Storage; `gcs` for Google Cloud Storage; and `s3` for Amazon S3, MinIO, or {odf-full}. For example: `s3`.
<7> The size of the persistent volume claim for the Tempo Write-Ahead Logging (WAL). The default is `10Gi`. For example: `1Gi`.
<8> The value must be `openshift`.
<9> The list of tenants.
<10> The tenant name, which is to be provided in the `X-Scope-OrgId` header when ingesting the data.
<11> The unique identifier of the tenant. Must be unique throughout the lifecycle of the TempoStack deployment. The {TempoShortName} uses this ID to prefix objects in the object storage. You can reuse the value of the UUID or `tempoName` field.
<12> Enables a gateway that performs authentication and authorization. The Jaeger UI is exposed at `+http://<gateway_ingress>/api/traces/v1/<tenant_name>/search+`.
<13> Exposes the Jaeger UI, which visualizes the data, via a route.
Revised: <3> Red{nbsp}Hat supports only the custom resource options that are available in the {DTProductName} documentation.
Original: * Previously, if you added a custom certificate with a Subject Alternative Name (SAN) that conflicted with the Kubernetes API server (KAS) hostname defined in `hc.spec.services.servicePublishingStrategy`, the KAS certificate was not included when generating a new payload. All new nodes that attempted to join the {hcp} cluster had certificate validation issues. With this release, a validation step prevents these conflicts and informs the user about the problem. (link:https://issues.redhat.com/browse/OCPBUGS-55697[OCPBUGS-55697])
Revised: * Previously, if you added a custom certificate with a Subject Alternative Name (SAN) that conflicted with the Kubernetes API server (KAS) hostname defined in `hc.spec.services.servicePublishingStrategy` parameter, the KAS certificate was not included when generating a new payload. All new nodes that attempted to join the {hcp} cluster had certificate validation issues. With this release, a validation step prevents these conflicts and informs the user about the problem. (link:https://issues.redhat.com/browse/OCPBUGS-55697[OCPBUGS-55697])
Original: * Previously, routes with secure hash algorithm (SHA-1) certificate authority (CA) certificates caused the high availability proxy (HAProxy) reload to fail. As a consequence, service interruptions occurred during reload operations. With this release, the validation is updated to reject routes with SHA-1 CA certificates. As a result, the `HAProxy`  prevents reload failures and ensures smooth operation.  (link:https://issues.redhat.com/browse/OCPBUGS-49391[OCPBUGS-49391])
Revised: * Previously, routes with secure hash algorithm (SHA-1) certificate authority (CA) certificates caused the high availability proxy (`HAProxy`) reload to fail. As a consequence, service interruptions occurred during reload operations. With this release, the validation is updated to reject routes with SHA-1 CA certificates. As a result, the `HAProxy`  prevents reload failures and ensures smooth operation.  (link:https://issues.redhat.com/browse/OCPBUGS-49391[OCPBUGS-49391])
Original: * Previously, large-scale {product-title} clusters with 4,000 egress firewall policies experienced failures in the ovn-kube controller. This was due to excessively long synchronization times, which blocked migration processes and led to worker node reboots. With this release, the `InformerSyncTimeout` for the `EgressFirewall` informer is increased to accommodate high-load scenarios. As a result, large-scale {product-title} cluster migrations are not halted by worker node reboots, ensuring a smoother and reliable migration operation. (link:https://issues.redhat.com/browse/OCPBUGS-48121[OCPBUGS-48121])
Revised: * Previously, large-scale {product-title} clusters with 4,000 egress firewall policies experienced failures in the ovn-kube controller during migration. This was due to excessively long synchronization times, which blocked migration processes and led to worker node reboots. With this release, the `InformerSyncTimeout` parameter for the `EgressFirewall` informer is increased to accommodate high-load scenarios. As a result, large-scale {product-title} cluster migrations are not halted by worker node reboots, ensuring a smoother and reliable migration operation. (link:https://issues.redhat.com/browse/OCPBUGS-48121[OCPBUGS-48121])
Original: // Back fill advisory when it is created by Konflux
// The following advisory is available for {coo-full} 1.2:
//
// * link:https://access.redhat.com/errata/RHSA-2025:????[RHEA-2025:??? {coo-full} 1.2]
Revised: The following advisory is available for {coo-full} 1.2:
Original: // Back fill advisory when it is created by Konflux
// The following advisory is available for {coo-full} 1.2:
//
// * link:https://access.redhat.com/errata/RHSA-2025:????[RHEA-2025:??? {coo-full} 1.2]
* Accelerators Perses dashboards are deployed by default when you install the monitoring UI plugin. (link:https://issues.redhat.com/browse/COO-942[*COO-942*])
Revised: * Accelerators Perses dashboards are deployed by default when you install the monitoring UI plugin. (link:https://issues.redhat.com/browse/COO-942[COO-942])
Original: // Back fill advisory when it is created by Konflux
// The following advisory is available for {coo-full} 1.2:
//
// * link:https://access.redhat.com/errata/RHSA-2025:????[RHEA-2025:??? {coo-full} 1.2]
* Accelerators Perses dashboards are deployed by default when you install the monitoring UI plugin. (link:https://issues.redhat.com/browse/COO-942[*COO-942*])
* Multiple results per graph node are now displayed for Korrel8r. (link:https://issues.redhat.com/browse/COO-785[*COO-785*])
Revised: * Multiple results per graph node are now displayed for Korrel8r. (link:https://issues.redhat.com/browse/COO-785[COO-785])
Original: // Back fill advisory when it is created by Konflux
// The following advisory is available for {coo-full} 1.2:
//
// * link:https://access.redhat.com/errata/RHSA-2025:????[RHEA-2025:??? {coo-full} 1.2]
* Accelerators Perses dashboards are deployed by default when you install the monitoring UI plugin. (link:https://issues.redhat.com/browse/COO-942[*COO-942*])
* Multiple results per graph node are now displayed for Korrel8r. (link:https://issues.redhat.com/browse/COO-785[*COO-785*])
Revised: * Direct navigation to individual incident detail is now supported in the incident detection panel, and this enables the incidents overview functionality in {rh-rhacm-first} 2.14. (link:https://issues.redhat.com/browse/COO-977[COO-977], link:https://issues.redhat.com/browse/ACM-18751[ACM-18751])
Original: // Back fill advisory when it is created by Konflux
// The following advisory is available for {coo-full} 1.2:
//
// * link:https://access.redhat.com/errata/RHSA-2025:????[RHEA-2025:??? {coo-full} 1.2]
* Accelerators Perses dashboards are deployed by default when you install the monitoring UI plugin. (link:https://issues.redhat.com/browse/COO-942[*COO-942*])
* Multiple results per graph node are now displayed for Korrel8r. (link:https://issues.redhat.com/browse/COO-785[*COO-785*])
* Advanced filters have been added to the tracing view. (link:https://issues.redhat.com/browse/COO-979[*COO-979*])
Revised: * Advanced filters have been added to the tracing view. (link:https://issues.redhat.com/browse/COO-979[COO-979])
Original: // Back fill advisory when it is created by Konflux
// The following advisory is available for {coo-full} 1.2:
//
// * link:https://access.redhat.com/errata/RHSA-2025:????[RHEA-2025:??? {coo-full} 1.2]
* Accelerators Perses dashboards are deployed by default when you install the monitoring UI plugin. (link:https://issues.redhat.com/browse/COO-942[*COO-942*])
* Multiple results per graph node are now displayed for Korrel8r. (link:https://issues.redhat.com/browse/COO-785[*COO-785*])
* Advanced filters have been added to the tracing view. (link:https://issues.redhat.com/browse/COO-979[*COO-979*])
* The status of the distributed tracing UI plugin is now General Availability (GA), supporting Patternfly 4, 5 and 6. (link:https://issues.redhat.com/browse/COO-873[*COO-873*])
Revised: * The status of the distributed tracing UI plugin is now General Availability (GA), supporting Patternfly 4, 5 and 6. (link:https://issues.redhat.com/browse/COO-873[COO-873])
Original: * Previously, when users added a custom certificate with a Subject Alternative Name (SAN) that conflicted with the Kubernetes API server (KAS) hostname defined in `hc.spec.services.servicePublishingStrategy`, the KAS certificate was not included in the new payload generation. This caused an issue with certificate validation for new nodes attempting to join the {hcp} cluster. With this release, a new validation is implemented to proactively identify and alert users about conflicts, and ensure that this bug no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-57321[OCPBUGS-57321])
Revised: * Previously, when users added a custom certificate with a Subject Alternative Name (SAN) that conflicted with the Kubernetes API server (KAS) hostname defined in `hc.spec.services.servicePublishingStrategy` parameter, the KAS certificate was not included in the new payload generation. This caused an issue with certificate validation for new nodes attempting to join the {hcp} cluster. With this release, a new validation is implemented to proactively identify and alert users about conflicts ensuring this bug no longer occurs. (link:https://issues.redhat.com/browse/OCPBUGS-57321[OCPBUGS-57321])
Original: * Previously, {product-title} version 4.16.37 experienced build failures. This was caused by the incorrect handling of proxy environment variables, which led to errors with external binaries and failed builds due to improperly formatted proxy settings. With this release, the issue is resolved by excluding proxy variables from the build process when they are not configured, This fix ensures that builds do not fail because of these variables. (link:https://issues.redhat.com/browse/OCPBUGS-56951[OCPBUGS-56951])
Revised: * Previously, {product-title} version 4.14.37 (?) experienced build failures. This was caused by the incorrect handling of proxy environment variables, which led to errors with external binaries and failed builds due to improperly formatted proxy settings. With this release, the issue is resolved by excluding proxy variables from the build process when they are not configured. This fix ensures that builds do not fail because of these variables. (link:https://issues.redhat.com/browse/OCPBUGS-56951[OCPBUGS-56951])
Original: * Previously, during the Time-Grandmaster (T-GM) holdover, if the global navigation satellite system (GNSS) source was re-acquired, the system would incorrectly announce a `T-GM-STATUS` of `S2` before the DPLL (Digital Phase-Locked Loop) had achieved a locked state. This premature announcement compromised T-GM stability and led to inaccurate status reports following GNSS re-acquisition. With this release, the DPLL now verifies T-GM status against GNSS source availability before declaring an S2 state. This crucial change ensures that end users will experience improved T-GM stability and receive correct status announcements immediately after GNSS re-acquisition. (link:https://issues.redhat.com/browse/OCPBUGS-55467[OCPBUGS-55467])
Revised: * Previously, during the Time-Grandmaster (T-GM) holdover, if the global navigation satellite system (GNSS) source was reacquired, the system would incorrectly announce a `T-GM-STATUS` of `S2` before the DPLL (Digital Phase-Locked Loop) had achieved a locked state. This announcement compromised T-GM stability and led to inaccurate status reports following GNSS reacquisition. With this release, the DPLL now verifies T-GM status against GNSS source availability before declaring an `S2` state. This change improves T-GM stability and ensures status announcements are sent after GNSS reacquisition. (link:https://issues.redhat.com/browse/OCPBUGS-55467[OCPBUGS-55467])
Original: {product-title} release {product-version}.18 is now available. The list of bug fixes that are included in the update is documented in the link:https://access.redhat.com/errata/RHSA-2025:9725[RHSA-2025:9725] advisory. The RPM packages that are included in the update are provided by the link:https://access.redhat.com/errata/RHSA-2025:9726[RHSA-2025:9726] advisory.
Revised: {product-title} release {product-version}.19 is now available. The list of bug fixes that are included in the update is documented in the link:https://access.redhat.com/errata/RHSA-2025:9725[RHSA-2025:9725] advisory. The RPM packages that are included in the update are provided by the link:https://access.redhat.com/errata/RHSA-2025:9726[RHSA-2025:9726] advisory.
Original: * Previously, using Alertmanager apiVersion v1 in the `openshift-monitoring/cluster-monitoring-config` or `openshift-user-workload-monitoring/user-workload-monitoring-config` parameters caused {product-title} 4.19 to fail early with an `InvalidConfigXXX` error. This issue occurred because {product-title} 4.19 is using Prometheus v3 which does not support Alertmanager apiVersion v1. With this release, {cmo-first} sets `upgradable=false` if apiVersion v1 is detected in the config maps to prevent the `InvalidConfigXXX` error from occurring after upgrading to {product-title} 4.19. As a result, clusters upgrade through {product-title} 4.18.x before moving to {product-title} 4.19. (link:https://issues.redhat.com/browse/OCPBUGS-56251[OCPBUGS-56251])
Revised: * Previously, using Alertmanager apiVersion v1 in the `openshift-monitoring/cluster-monitoring-config` or `openshift-user-workload-monitoring/user-workload-monitoring-config` parameters caused {product-title} 4.19 to fail early with an `InvalidConfigXXX` error. This issue occurred because {product-title} 4.19 is using Prometheus v3 which does not support Alertmanager apiVersion v1. With this release, {cmo-first} sets a value of `upgradable=false` if apiVersion v1 is detected in the config maps to prevent the `InvalidConfigXXX` error from occurring after upgrading to {product-title} 4.19. As a result, clusters upgrade through {product-title} 4.18.x before moving to {product-title} 4.19. (link:https://issues.redhat.com/browse/OCPBUGS-56251[OCPBUGS-56251])
Original: * Machine configs are processed alphabetically, in lexicographically increasing order, by their name. The render controller uses the first machine config in the list as the base and appends the rest to the base machine config into a rendered machine config, which then gets applied to the appropriate nodes.
Revised: * Machine configs are processed alphabetically, in lexicographically increasing order, by their name. The render controller uses the first machine config in the list as the base and appends the rest to the base machine config into a rendered machine config, which then is applied to the appropriate nodes.
Original: * Previously, the installation program checked only the first compute machine pool entry in the install configuration to determine whether to disable the `MachineConfigOperator` (MCO) boot image management. If multiple compute pools were specified (Amazon Web Service (AWS) edge nodes are the only supported scenario), but another compute machine pool had a custom Amazon Machine Image (AMI), the installation program would not disable the MCO boot image management and the custom AMI would be overwritten by the MCO. With this release, the installation program checks all compute machine pool entries and if a custom image is found, the MCO boot image management is disabled. (link:https://issues.redhat.com/browse/OCPBUGS-58060[OCPBUGS-58060])
Revised: * Previously, the installation program checked only the first compute machine pool entry in the install configuration to determine whether to disable the Machine Config Operator (MCO) boot image management feature. If multiple compute pools were specified (Amazon Web Service (AWS) edge nodes are the only supported scenario), but another compute machine pool had a custom Amazon Machine Image (AMI), the installation program would not disable the MCO boot image management and the custom AMI would be overwritten by the MCO. With this release, the installation program checks all compute machine pool entries and if a custom image is found, the MCO boot image management is disabled. (link:https://issues.redhat.com/browse/OCPBUGS-58060[OCPBUGS-58060])
Original: * Previously, if a user specified a custom boot image for Amazon Web Services (AWS) or the Google Cloud Platform (GCP), the Machine Config Operator (MCO) would overwrite it with the default manage image during installation. With this release, a manifest generation was added for MCO configuration which disables the default managed image during installation if a custom image is specified. (link:https://issues.redhat.com/browse/OCPBUGS-57796[OCPBUGS-57796])
Revised: * Previously, if a user specified a custom boot image for Amazon Web Services (AWS) or the Google Cloud Platform (GCP), the Machine Config Operator (MCO) would overwrite it with the default boot image during installation. With this release, a manifest generation was added for MCO configuration which disables the default boot image during installation if a custom image is specified. (link:https://issues.redhat.com/browse/OCPBUGS-57796[OCPBUGS-57796])
Original: * The `oc-mirror v2` was not using the correct filtered catalog during its operations leading to errors such as including more operators than specified in the configuration, and trying to connect to the catalog registry during disk-to-mirror workflows even in air-gapped environments. With this release, the correct filtered catalog is used. (link:https://issues.redhat.com/browse/OCPBUGS-57784[OCPBUGS-57784])
Revised: * The `oc-mirror v2` was not using the correct filtered catalog during its operations, which led to errors such as including more operators than specified in the configuration, and trying to connect to the catalog registry during disk-to-mirror workflows even in air-gapped environments. With this release, the correct filtered catalog is used. (link:https://issues.redhat.com/browse/OCPBUGS-57784[OCPBUGS-57784])
Original: * Previously, the OpenShift Lightspeed UI would disappear when the *Create Project* modal was opened or when modals on the Networking pages were triggered. This was due to the modals using the `useModal` hook causing the modals to overwrite each other. With this release, the modals no longer overwrite each other allowing multiple UI elements to be displayed simultaneously. (link:https://issues.redhat.com/browse/OCPBUGS-57755[OCPBUGS-57755])
Revised: * Previously, the {ols-official} UI would disappear when the *Create Project* modal was opened or when modals on the Networking pages were triggered. This was due to the modals using the `useModal` hook causing the modals to overwrite each other. With this release, the modals no longer overwrite each other allowing multiple UI elements to be displayed simultaneously. (link:https://issues.redhat.com/browse/OCPBUGS-57755[OCPBUGS-57755])