gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: If service account is missing any required RBAC rules, the preflight check fails before the actual installation proceeds. If the preflight check fails, the Operator Controller reports the errors in the status conditions of the extension and in the logs of the Operator Controller.
Revised: If the service account is missing any required RBAC rules, the preflight check fails before the actual installation proceeds. If the preflight check fails, the Operator Controller reports the errors in the status conditions of the extension and in the logs of the Operator Controller.
Original: * Previously, network flows may have incorrectly identified the network interfaces in use, especially with a risk of mixing up `eth0` and `ens5`. This issue only occurred when the eBPF agents were configured as `Privileged`. With this update, the network interfaces should be correctly identified. (link:https://issues.redhat.com/browse/NETOBSERV-2257[*NETOBSERV-2257*])
Revised: * Previously, network flows may have incorrectly identified the network interfaces in use, especially with a risk of mixing up `eth0` and `ens5`. This issue only occurred when the eBPF agents were configured as `Privileged`. With this update, it has been fixed partially, and almost all network interfaces are correctly identified. Refer to the known issues below for more details. (link:https://issues.redhat.com/browse/NETOBSERV-2257[*NETOBSERV-2257*])
Original: * Previously, the console plugin for Network Observability 1.8.1 and earlier did not work with the {product-title} 4.19 web console, making the *Network Traffic* page inaccessible. With this update, the console plugin is compatible and the *Network Traffic* page is accessible for Network Observability 1.8.1 and earlier. (link:https://issues.redhat.com/browse/NETOBSERV-2046[*NETOBSERV-2046*])
Revised: * Previously, the console plugin for Network Observability 1.8.1 and earlier did not work with the {product-title} 4.19 web console, making the *Network Traffic* page inaccessible. With this update, the console plugin is compatible and the *Network Traffic* page is accessible in Network Observability 1.9.0. (link:https://issues.redhat.com/browse/NETOBSERV-2046[*NETOBSERV-2046*])
Original: With this release, the user-defined networks (UDN) feature is generally available with Network Observability. When the `UDNMapping` feature is enabled in Network Observability, the *Traffic* flow table has a `UDN labels` column. You can filter on *Source Network Name* and *Destination Network Name*.
Revised: With this release, the link:<xref>[user-defined networks (UDN)] feature is generally available with Network Observability. When the `UDNMapping` feature is enabled in Network Observability, the *Traffic* flow table has a `UDN labels` column. You can filter on *Source Network Name* and *Destination Network Name*.
Original: With this release, the user-defined networks (UDN) feature is generally available with Network Observability. When the `UDNMapping` feature is enabled in Network Observability, the *Traffic* flow table has a `UDN labels` column. You can filter on *Source Network Name* and *Destination Network Name*.
Revised: With this release, the user-defined networks (UDN) feature is generally available with Network Observability. When the `UDNMapping` feature is enabled in Network Observability, the *Traffic* flow table has a `UDN labels` column. You can filter logs on *Source Network Name* and *Destination Network Name* information.
Original: * The `NetworkEvents` feature in Network Observability 1.9 has been updated to work with the newer Linux kernel of {product-title} 4.19. This update breaks compatibility with older kernels. As a result, the `NetworkEvents` feature can only be used with {product-title} 4.19. If you are using this feature with Network Observability 1.8 and {product-title} 4.18, consider avoiding a Network Observability upgrade or upgrading both Network Observability 1.9 and {product-title} 4.19.
Revised: * The `NetworkEvents` feature in Network Observability 1.9 has been updated to work with the newer Linux kernel of {product-title} 4.19. This update breaks compatibility with older kernels. As a result, the `NetworkEvents` feature can only be used with {product-title} 4.19. If you are using this feature with Network Observability 1.8 and {product-title} 4.18, consider avoiding a Network Observability upgrade or upgrading Network Observability to 1.9 and {product-title} to 4.19.
Original: * Previously, network flows may have incorrectly identified the network interfaces in use, especially with a risk of mixing up `eth0` and `ens5`. This issue only occurred when the eBPF agents were configured as `Privileged`. With this update, it has been fixed partially, and almost all network interfaces are correctly identified. Refer to the known issues below for more details. (link:https://issues.redhat.com/browse/NETOBSERV-2257[*NETOBSERV-2257*])
Revised: * Previously, network flows might have incorrectly identified the network interfaces in use, especially with a risk of mixing up `eth0` and `ens5`. This issue only occurred when the eBPF agents were configured as `Privileged`. With this update, it has been fixed partially, and almost all network interfaces are correctly identified. Refer to the known issues below for more details. (link:https://issues.redhat.com/browse/NETOBSERV-2257[*NETOBSERV-2257*])
Original: * Previously, when the Operator checked for available Kubernetes APIs in order to adapt its behavior, if there was a stale API, this resulted in an error that prevented the Operator from starting normally. With this update, the Operator will ignore errors on unrelated APIs, will log errors on related APIs, and will continue to run normally. (link:https://issues.redhat.com/browse/NETOBSERV-2240[*NETOBSERV-2240*])
Revised: * Previously, when the Operator checked for available Kubernetes APIs in order to adapt its behavior, if there was a stale API, this resulted in an error that prevented the Operator from starting normally. With this update, the Operator ignores error on unrelated APIs, logs errors on related APIs, and continues to run normally. (link:https://issues.redhat.com/browse/NETOBSERV-2240[*NETOBSERV-2240*])
Original: * Previously, users could not sort flows by *Bytes* or *Packets* in the *Traffic* flows view of the Console plugin. With this update, users can sort flows as expected.(link:https://issues.redhat.com/browse/NETOBSERV-2239[*NETOBSERV-2239*])
Revised: * Previously, users could not sort flows by *Bytes* or *Packets* in the *Traffic* flows view of the Console plugin. With this update, users can sort flows by *Bytes* and *Packets*.(link:https://issues.redhat.com/browse/NETOBSERV-2239[*NETOBSERV-2239*])
Original: * Previously, in the console plugin *Traffic flows* view, in case of text overflow, text ellipsis sometimes hid much of the text to be displayed. With this update, it displays as much text as possible. (link:https://issues.redhat.com/browse/NETOBSERV-2119[*NETOBSERV-2119*])
Revised: * Previously, in the console plugin *Traffic flows* view, in case of text overflow, text ellipses sometimes hid much of the text to be displayed. With this update, it displays as much text as possible. (link:https://issues.redhat.com/browse/NETOBSERV-2119[*NETOBSERV-2119*])
Original: * Previously, when using conversation tracking (`logTypes: Conversations` or `logTypes: All` in the `FlowCollector` resource), the *Traffic* rates metrics visible in the dashboards were flawed, wrongly showing an seemingly out-of-control increase in traffic. Now, the metrics show more accurate traffic rates. However, note that in `Conversations` and `EndedConversations` modes, these metrics are still not 100% accurate as they don't include long-standing connections. This information has been added to the documentation. The default mode `logTypes: Flows`, is recommended to avoid this kind of inaccuracy. (link:https://issues.redhat.com/browse/NETOBSERV-1955[*NETOBSERV-1955*])
Revised: * Previously, when using conversation tracking (`logTypes: Conversations` or `logTypes: All` in the `FlowCollector` resource), the *Traffic* rates metrics visible in the dashboards were flawed, wrongly showing an out-of-control increase in traffic. Now, the metrics show more accurate traffic rates. However, note that in `Conversations` and `EndedConversations` modes, these metrics are still not 100% accurate as they don't include long-standing connections. This information has been added to the documentation. The default mode `logTypes: Flows`, is recommended to avoid this kind of inaccuracy. (link:https://issues.redhat.com/browse/NETOBSERV-1955[*NETOBSERV-1955*])
Original: * The `NetworkEvents` feature in Network Observability 1.9 has been updated to work with the newer Linux kernel of {product-title} 4.19. This update breaks compatibility with older kernels. As a result, the `NetworkEvents` feature can only be used with {product-title} 4.19. If you are using this feature with Network Observability 1.8 and {product-title} 4.18, consider avoiding a Network Observability upgrade or upgrading Network Observability to 1.9 and {product-title} to 4.19.
Revised: * The `NetworkEvents` feature in Network Observability 1.9 has been updated to work with the newer Linux kernel of {product-title} 4.19. This update breaks compatibility with older kernels. As a result, the `NetworkEvents` feature can only be used with {product-title} 4.19. If you are using this feature with Network Observability 1.8 and {product-title} 4.18, consider avoiding a Network Observability upgrade or upgrade to Network Observability 1.9 and {product-title} to 4.19.
Original: * Previously, users could not sort flows by *Bytes* or *Packets* in the *Traffic* flows view of the Console plugin. With this update, users can sort flows by *Bytes* and *Packets*.(link:https://issues.redhat.com/browse/NETOBSERV-2239[*NETOBSERV-2239*])
Revised: * Previously, users could not sort flows by *Bytes* or *Packets* in the *Traffic* flows view of the Console plugin. With this update, users can sort flows by *Bytes* and *Packets*. (link:https://issues.redhat.com/browse/NETOBSERV-2239[*NETOBSERV-2239*])
Original: * Previously, some of the warnings sent from the Operator validation webhook could lack clarity, such as when not mentioning exactly which feature causes the warning, or what needed to be done. With this update, some of these messages have been reviewed and amended to make them more actionable. (link:https://issues.redhat.com/browse/NETOBSERV-2178[*NETOBSERV-2178*])
Revised: * Previously, some of the warnings sent from the Operator validation webhook could lack clarity on what needed to be done. With this update, some of these messages have been reviewed and amended to make them more actionable. (link:https://issues.redhat.com/browse/NETOBSERV-2178[*NETOBSERV-2178*])
Original: * Previously, when using conversation tracking (`logTypes: Conversations` or `logTypes: All` in the `FlowCollector` resource), the *Traffic* rates metrics visible in the dashboards were flawed, wrongly showing an out-of-control increase in traffic. Now, the metrics show more accurate traffic rates. However, note that in `Conversations` and `EndedConversations` modes, these metrics are still not 100% accurate as they don't include long-standing connections. This information has been added to the documentation. The default mode `logTypes: Flows`, is recommended to avoid this kind of inaccuracy. (link:https://issues.redhat.com/browse/NETOBSERV-1955[*NETOBSERV-1955*])
Revised: * Previously, when using conversation tracking (`logTypes: Conversations` or `logTypes: All` in the `FlowCollector` resource), the *Traffic* rates metrics visible in the dashboards were flawed, wrongly showing an out-of-control increase in traffic. Now, the metrics show more accurate traffic rates. However, note that in `Conversations` and `EndedConversations` modes, these metrics are still not completely accurate as they do not include long-standing connections. This information has been added to the documentation. The default mode `logTypes: Flows` is recommended to avoid these inaccuracy. (link:https://issues.redhat.com/browse/NETOBSERV-1955[*NETOBSERV-1955*])
Original: * In some rare cases, the eBPF agent is unable to appropriately correlate flows with the involved interfaces when running in privileged modes with several network namespaces. A large part of these issues have been identified and resolved in this release, but some inconsistencies remain, especially with the `ens5` interface. (link:https://issues.redhat.com/browse/NETOBSERV-2287[*NETOBSERV-2287*])
Revised: * In some rare cases, the eBPF agent is unable to appropriately correlate flows with the involved interfaces when running in `privileged` modes with several network namespaces. A large part of these issues have been identified and resolved in this release, but some inconsistencies remain, especially with the `ens5` interface. (link:https://issues.redhat.com/browse/NETOBSERV-2287[*NETOBSERV-2287*])
Original: {product-title} release {product-version}.31 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:8552[RHSA-2025:8552] advisory. The RPM packages that are included in the update are provided by the link:https://access.redhat.com/errata/RHBA-2025:8553[RHBA-2025:8553] advisory.
Revised: {product-title} release {product-version}.33 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:8552[RHSA-2025:8552] advisory. The RPM packages that are included in the update are provided by the link:https://access.redhat.com/errata/RHBA-2025:8553[RHBA-2025:8553] advisory.
Original: * There is currently a known issue where a Technology Preview-enabled cluster has Sigstore verification for payload images in `policy.json`, but the Podman version in the base image does not support Sigstore configuration, so the new node is not available.
Revised: * Currently, a Technology Preview-enabled cluster has Sigstore verification for payload images in `policy.json`, but the Podman version in the base image does not support Sigstore configuration, so the new node is not available.
Original: Workaround: The node will start running when the Podman version in the base image does not support Sigstore. Use the default `policy.json` that does not have Sigstore verification if the base image is 4.11 or earlier. (link:https://issues.redhat.com/browse/OCPBUGS-52313[OCPBUGS-52313])
Revised: Workaround: The node starts running when the Podman version in the base image does not support Sigstore. Use the default `policy.json` that does not have Sigstore verification if the base image is 4.11 or earlier. (link:https://issues.redhat.com/browse/OCPBUGS-52313[OCPBUGS-52313])
Original: * Previously, there was no communication between a `localnet` pod and a pod in the default network, when both pods are on the same node. With this release, an update fixes this problem when the endpoints were on a different node. (link:https://issues.redhat.com/browse/OCPBUGS-56244[OCPBUGS-56244])
Revised: * Previously, there was no communication between a `localnet` pod and a pod in the default network when both pods were on the same node. With this release, an update fixes this problem when the endpoints were on a different node. (link:https://issues.redhat.com/browse/OCPBUGS-56244[OCPBUGS-56244])
Original: With this release, you can configure {azure-first} to enable boot diagnostics collection when you install a cluster. You can set the `bootDiagnostics` parameter in the `install-config.yaml` file for compute machines, for control plane machines, or for all machines.
Revised: With this release, you can enable boot diagnostics collection when you install a cluster on {azure-first}. You can set the `bootDiagnostics` parameter in the `install-config.yaml` file for compute machines, for control plane machines, or for all machines.
Original: For more information, see xref:../installing/installing_gcp/installation-config-parameters-gcp.adoc#installation-config-parameters-additional-gcp_installation-config-parameters-gcp[Additional {gcp-full} configuration parameters].
Revised: For more information, see xref:../installing/installing_gcp/installation-config-parameters-gcp.adoc#installation-config-parameters-additional-gcp_installation-config-parameters-gcp[Installation configuration parameters for {gcp-full}] .
Original: Previously, in-memory loopback certificates in kube-apiserver were issued for one year. This meant that if the kube-apiserver ran without rollouts or updates it would stop functioning after one year. In {product-title} {product-version} the in-memory loopback certificates are extended so the kube-apiserver can run for three years without interruption.
Revised: Previously, in-memory loopback certificates in kube-apiserver were issued for one year. This meant that if the kube-apiserver ran without rollouts or restarts it would stop functioning after one year. In {product-title} {product-version} the in-memory loopback certificates are extended so the kube-apiserver can run for three years without interruption.
Original: Previously, in-memory loopback certificates in kube-apiserver were issued for one year. This meant that if the kube-apiserver ran without rollouts or restarts it would stop functioning after one year. In {product-title} {product-version} the in-memory loopback certificates are extended so the kube-apiserver can run for three years without interruption.
Revised: Previously, in-memory loopback certificates in kube-apiserver were issued for one year. This meant that if the kube-apiserver ran without rollouts or restarts, the kube-apiserver would stop functioning after one year. In {product-title} {product-version} the in-memory loopback certificates are extended so the kube-apiserver can run for three years without interruption.
Original: In {product-title} {product-version}, the `ServiceAccountTokenNodeBinding` feature is now enabled by default, aligning with upstream Kubernetes behavior. This feature allows service account tokens to be bound directly to Node objects in addition to the existing binding options. Benefits of this change include enhanced security through automatic token invalidation when bound nodes are deleted and  better protection against token replay attacks across different nodes.
Revised: In {product-title} {product-version}, the `ServiceAccountTokenNodeBinding` feature is now enabled by default, aligning with upstream Kubernetes behavior. This feature allows service account tokens to be bound directly to node objects in addition to the existing binding options. Benefits of this change include enhanced security through automatic token invalidation when bound nodes are deleted and better protection against token replay attacks across different nodes.
Original: In the 4.19 release, a bug is fixed in which the kubelet incorrectly calculated `readinessProbe` periods. Previously, the kubelet wouldn't account for probes run in the `syncPod` method, which periodically checks the state of a pod and does a readiness probe outside of the normal probe period. With this release, pod readiness latency when configured with readiness probes may increase, but is more accurate to the configured probe. For more information, see (link:https://issues.redhat.com/browse/OCPBUGS-50522[OCPBUGS-50522])
Revised: * Previously, the kubelet would not account for probes that ran in the `syncPod` method, which periodically checks the state of a pod and does a readiness probe outside of the normal probe period. With this release, a bug is fixed for when the kubelet incorrectly calculates `readinessProbe` periods. However, pod readiness latency when configured with readiness probes might increase, but the readiness probe approach is more accurate when compared to the configured probe. For more information, see (link:https://issues.redhat.com/browse/OCPBUGS-50522[OCPBUGS-50522])
Original: Previously, the kubelet would not account for probes that ran in the `syncPod` method, which periodically checks the state of a pod and does a readiness probe outside of the normal probe period. With this release, a bug is fixed for when the kubelet incorrectly calculates `readinessProbe` periods. However, pod authors may see that the readiness latency of pods configured with readiness probes may increase. This behavior is more accurate to the configured probe. For more information, see (link:https://issues.redhat.com/browse/OCPBUGS-50522[OCPBUGS-50522])
Revised: Previously, the kubelet would not account for probes that ran in the `syncPod` method, which periodically checks the state of a pod and does a readiness probe outside of the normal probe period. With this release, a bug is fixed for when the kubelet incorrectly calculates `readinessProbe` periods. However, pod authors might see that the readiness latency of pods configured with readiness probes might increase. This behavior is more accurate to the configured probe. For more information, see (link:https://issues.redhat.com/browse/OCPBUGS-50522[OCPBUGS-50522])
Original: These dependencies include:

* Python
* Ansible
* The Python modules:
** `openstackclient`
** `openstacksdk`
** `netaddr`
* The Ansible collections:
** `openstack.cloud`
** `community.general`
Revised: These dependencies include:

* The Python modules:
** `openstackclient`
** `openstacksdk`
** `netaddr`
* The Ansible collections:
** `openstack.cloud`
** `community.general`
Original: The Ansible playbooks that simplify the installation process on user-provisioned
infrastructure require several Python modules. On the machine where you will run the installer,
add the modules' repositories and then download them.
Revised: The Ansible playbooks that simplify the installation process on user-provisioned
infrastructure require several ansible collections and Python modules. On the machine
where you will run the installer, add the {rh-openstack-first} repositories and then install packages.
Original: --enable=rhel-8-for-x86_64-baseos-rpms \
--enable=openstack-16-tools-for-rhel-8-x86_64-rpms \
--enable=ansible-2.9-for-rhel-8-x86_64-rpms \
--enable=rhel-8-for-x86_64-appstream-rpms
$ sudo yum install python3-openstackclient ansible python3-openstacksdk python3-netaddr ansible-collections-openstack
Revised: python3-openstackclient \
python3-openstacksdk \
Original: The Ansible playbooks that simplify the installation process on user-provisioned
infrastructure require several Python modules. On the machine where you will run the installer,
add the modules' repositories and then download them.
Revised: The Ansible playbooks that simplify the installation process on user-provisioned
infrastructure require several ansible collections and Python modules. On the machine
where you will run the installer, add the {rh-openstack-first} repositories and then install the packages.
Original: infrastructure require several Python modules. On the machine where you will run the installer,
add the modules' repositories and then download them.
Revised: The following dependencies are required:

* Python modules:
** `openstackclient`
** `openstacksdk`
** `netaddr`
** `pip`
* Ansible collections:
** `ansible-collections-openstack`, which installs Ansible Core
** `ansible-collection-community-general`
** `ansible-collection-ansible-netcommon`
Original: . Navigate to *Virtualization* -> *VirtualMachines* in the web console.
. Select a VM to open the *VirtualMachine details* page.
. Click *Actions*.
Revised: . In the web console, click  *Virtualization* -> *VirtualMachines* to do any of the following tasks:
** To open the *VirtualMachine details* page, select a VM, and then click *Actions*.
** In the tree view, right-click the VM, and then click *Actions*.
Original: . Click *Actions* and select the intended action from the menu.
+
Alternatively, you can change the state of all VMs in a project by right-clicking the project in the tree view and selecting the intended command from the pop-up menu.
Revised: . To change the state of all the VMs in a project, do any of the following tasks:
** Click *Actions*, and then on the pop-up menu, select the intended action.
** In the tree view, right-click the project, and then on the pop-up menu, select the intended action.