gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: .`UserDefinedNetworks` optional configurations
[cols="1,1,7", options="header"]
|Field|Type|Description
|`spec.joinSubnets`
|`spec.ipam.lifecycle`
|The `spec.ipam.lifecycle` field configures the IP address management system (IPAM). You might use this field for virtual workloads to ensure persistent IP addresses. The only allowed value is `Persistent`, which
ensures that your virtual workloads have persistent IP addresses across reboots and migration. These are assigned by the container network interface (CNI) and used by OVN-Kubernetes to program pod IP addresses. You must not change this for pod annotations.
Setting a value of `Persistent` is only supported when `spec.ipam.mode` is set to `Enabled`.
|`spec.ipam.mode`
Revised: |The `mode` field controls how much of the IP configuration is managed by OVN-Kubernetes. The following options are available:
Original: <1> The provided `5000` and `10000` values are examples. You can roughly estimate the desired latency values by looking at the earliest start time value and latest end time value. If you omit the `upper_threshold_ms` field, this policy samples all latencies greater than the specified `threshold_ms` value.
Revised: <1> The provided `5000` and `10000` values are examples. You can estimate the desired latency values by looking at the earliest start time value and latest end time value. If you omit the `upper_threshold_ms` field, this policy samples all latencies greater than the specified `threshold_ms` value.
Original: <1> Allocates percentages of spans according to the order of applied policies. For example, if you set the `100` value in the `max_total_spans_per_second` field, you can set the following values in the `rate_allocation` section: the `50` percent value in the `policy: <composite_policy_1>` section to allocate 50 spans per second, and the `25` percent value in the `policy: <composite_policy_2>` section to allocate 25 spans per second. And to fill the remaining capacity, you can set the `always_sample` value in the `type` field of the `name: <composite_policy_3>` section.
Revised: <1> Allocates percentages of spans according to the order of applied policies. For example, if you set the `100` value in the `max_total_spans_per_second` field, you can set the following values in the `rate_allocation` section: the `50` percent value in the `policy: <composite_policy_1>` section to allocate 50 spans per second, and the `25` percent value in the `policy: <composite_policy_2>` section to allocate 25 spans per second. To fill the remaining capacity, you can set the `always_sample` value in the `type` field of the `name: <composite_policy_3>` section.
Original: The changes that we make to the component routes{fn-term-component-routes} in this guide are described in greater detail in the customizing the link:https://docs.openshift.com/container-platform/latest/authentication/configuring-internal-oauth.html#customizing-the-oauth-server-url_configuring-internal-oauth[internal OAuth server URL], link:https://docs.openshift.com/container-platform/latest/web_console/customizing-the-web-console.html#customizing-the-console-route_customizing-web-console[console route], and link:https://docs.openshift.com/container-platform/latest/web_console/customizing-the-web-console.html#customizing-the-download-route_customizing-web-console[download route] OpenShift Container Platform documentation.
Revised: The changes that we make to the component routes{fn-term-component-routes} in this guide are described in greater detail in the customizing the link:https://docs.openshift.com/container-platform/latest/authentication/configuring-internal-oauth.html#customizing-the-oauth-server-url_configuring-internal-oauth[internal OAuth server URL], link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/web_console/customizing-web-console#creating-custom-links_customizing-web-console[console route], and link:https://docs.redhat.com/en/documentation/openshift_container_platform/4.18/html/web_console/customizing-web-console#customizing-the-download-route_customizing-web-console[download route] OpenShift Container Platform documentation.
Original: * The runbook for the `VirtualMachineCRCErrors` alert is deprecated because the alert was renamed to `VMStorageClassWarning`.
** link:https://github.com/openshift/runbooks/blob/master/alerts/openshift-virtualization-operator/VMStorageClassWarning.md[View the runbook] for the `VMStorageClassWarning` alert.
Revised: The alert is now called `VMStorageClassWarning`.
Original: . Optional: To disable a monitoring dashboards in a hosted cluster, remove the `--monitoring-dashboards` flag from the `hypershift-operator-install-flags` config map. When you delete a hosted cluster, its corresponding dashboard is also deleted.
Revised: . Optional: To disable monitoring dashboards in a hosted cluster, remove the `--monitoring-dashboards --metrics-set=All` flag from the `hypershift-operator-install-flags` config map. When you delete a hosted cluster, its corresponding dashboard is also deleted.
Original: You can find the architecture diagrams for the Kourier and Istio ingresses on the link:https://openshift-knative.github.io/docs/docs/latest/serverless/serving/serving-kourier-istio-ingresses#serverless-ingresses-traffic-configuration-and-routing[Technology and Developer Preview Releases] site.
Revised: You can find the architecture diagrams for the Kourier and Istio ingresses on the link:https://openshift-knative.github.io/docs/docs/latest/serverless/serving/serving-kourier-istio-ingresses#serverless-ingresses-traffic-configuration-and-routing[Technology and Developer Preview Releases] website.
Original: To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) clusters and is not supported for {cluster-capi-operator} managed clusters.
Revised: To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only {gcp-first} clusters as GA and {aws-first} clusters as a Technology Preview and is not supported for {cluster-capi-operator} managed clusters.
Original: To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) clusters and is not supported for {cluster-capi-operator} managed clusters.
Revised: To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) clusters as a Generally Available (GA) feature and Amazon Web Services (AWS) clusters as a Technology Preview feature and is not supported for {cluster-capi-operator} managed clusters.
Original: To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) clusters and is not supported for {cluster-capi-operator} managed clusters.
:FeatureName: The updating boot image feature
Revised: :FeatureName: The updating boot image feature on {aws-short} clusters
Original: To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) clusters and is not supported for {cluster-capi-operator} managed clusters.
Revised: To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only {gcp-first} clusters as a Technology Preview and is not supported for {cluster-capi-operator} managed clusters.
Original: To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) clusters and is not supported for {cluster-capi-operator} managed clusters.
:FeatureName: The updating boot image feature
Revised: :FeatureName: The updating boot image feature on {gcp-short} clusters
Original: To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) clusters and is not supported for {cluster-capi-operator} managed clusters.
Revised: To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) clusters as a Technology Preview feature and is not supported for {cluster-capi-operator} managed clusters.
Original: To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only Google Cloud Platform (GCP) clusters and is not supported for {cluster-capi-operator} managed clusters.
Revised: To avoid these issues, you can configure your cluster to update the boot image whenever you update your cluster. By modifying the `MachineConfiguration` object, you can enable this feature. Currently, the ability to update the boot image is available for only {gcp-first} clusters as a Technology Preview feature and is not supported for {cluster-capi-operator} managed clusters.
Original: :zero-trust-full: zero trust workload identity manager for Red{nbsp}Hat OpenShift
Revised: :zero-trust-full: Zero Trust Workload Identity Manager for Red{nbsp}Hat OpenShift
:zero-trust-short: Zero Trust Workload Identity Manager
:spiffe-full: Secure Production Identity Framework for Everyone (SPIFFE)
:svid-full: SPIFFE Verifiable Identity Document (SVID)
Original: * On the *VirtualMachines* page, you can now see the summary of CPU, memory, and storage usage by your VMs. To restrict this summary to VMs in a specific project, select the project name in the tree view.
Revised: * On the *VirtualMachines* page, you can now see the summary of CPU, memory, and storage usage by your VMs. To restrict this summary to the VMs in a specific project, select the project name in the tree view.
Original: [NOTE]
====
For FCP multipath configurations, provide two disks instead of one.
====
+
.Example 
[source,yaml]
----
rd.zfcp=<adapter1>,<wwpn1>,<lun1> \
rd.zfcp=<adapter2>,<wwpn2>,<lun2>
----
+
Revised: [NOTE]
====
For FCP multipath configurations, provide two disks instead of one.
====

.Example
[source,yaml]
rd.zfcp=<adapter1>,<wwpn1>,<lun1> \
rd.zfcp=<adapter2>,<wwpn2>,<lun2>
Original: [NOTE]
====
For FCP multipath configurations, provide two disks instead of one.
====
+
.Example 
[source,yaml]
----
rd.zfcp=<adapter1>,<wwpn1>,<lun1> \
rd.zfcp=<adapter2>,<wwpn2>,<lun2>
----
+
<5> For installations on FCP-type disks, use `rd.zfcp=<adapter>,<wwpn>,<lun>` to specify the FCP disk where {op-system} is to be installed. Omit this entry for DASD-type disks.
Revised: [NOTE]
====
For FCP multipath configurations, provide two disks instead of one.
====

.Example
[source,yaml]
rd.zfcp=<adapter1>,<wwpn1>,<lun1> \
rd.zfcp=<adapter2>,<wwpn2>,<lun2>
Original: When the etcd client requests an action that requires a quorum, such as writing a value, from the leader, the leader maintains the client connection open while it writes the local Raft log, broadcasts the log to the followers, and waits for the majority of the followers to acknowledge to have committed the log without failures. The leader sends the acknowledgment to the etcd client and closes the session. If failure notifications are received from the clients and fail to reach a consensus, the leader returns the error message to the client and closes the session.
Revised: When the etcd client requests an action that requires a quorum, such as writing a value, from the leader, the leader maintains the client connection open while it writes the local Raft log, broadcasts the log to the followers, and waits for the majority of the followers to acknowledge to have committed the log without failures. The leader sends the acknowledgment to the etcd client and closes the session. If failure notifications are received from the followers and fail to reach a consensus, the leader returns the error message to the client and closes the session.
Original: etcd holds the cluster state, which is constantly updated. This state is continuously persisted, which leads to a high number of small changes at high frequency. As a result, it is critical to back up the etcd cluster member with fast, low-latency I/O. For more information about best practices for etcd, see _Recommended etcd practices_.
Revised: etcd holds the cluster state, which is constantly updated. This state is continuously persisted, which leads to a high number of small changes at high frequency. As a result, it is critical to back up the etcd cluster member with fast, low-latency I/O. For more information about best practices for etcd, see "Recommended etcd practices".
Original: As a consistent distributed key-value store operating as a cluster of replicated nodes, etcd follows the Raft algorithm by electing one node as the leader and the others as followers. The leader maintains the system's current state and ensures that the followers are up-to-date.
Revised: As a consistent distributed key-value store operating as a cluster of replicated nodes, etcd follows the Raft algorithm by electing one node as the leader and the others as followers. The leader maintains current state of the system current state and ensures that the followers are up-to-date.
Original: When the etcd client requests an action that requires a quorum, such as writing a value, from the leader, the leader maintains the client connection open while it writes the local Raft log, broadcasts the log to the followers, and waits for the majority of the followers to acknowledge to have committed the log without failures. The leader sends the acknowledgment to the etcd client and closes the session. If failure notifications are received from the followers and fail to reach a consensus, the leader returns the error message to the client and closes the session.
Revised: When the etcd client requests an action from the leader that requires a quorum, such as writing a value, the leader maintains the client connection while it writes the local Raft log, broadcasts the log to the followers, and waits for the majority of the followers to acknowledge to have committed the log without failures. The leader sends the acknowledgment to the etcd client and closes the session. If failure notifications are received from the followers and a consensus is not met, the leader returns the error message to the client and closes the session.
Original: {product-title} maintains etcd timers that are optimized for each platform. {product-title} has prescribed validated values that are optimized for each platform provider. The default `etcd timers` with `platform=none` or `platform=metal` are as follows:
Revised: {product-title} maintains etcd timers that are optimized for each platform. {product-title} has prescribed validated values that are optimized for each platform provider. The default `etcd timers` parameters with `platform=none` or `platform=metal` values are as follows:
Original: An etcd cluster is sensitive to disk latencies. To understand the disk latency that is experienced by etcd in your control plane environment, run the Flexible I/O Tester (fio) tests or suite, to check etcd disk performance in {product-title}.
Revised: An etcd cluster is sensitive to disk latencies. To understand the disk latency that etcd experiences in your control plane environment, run the Flexible I/O Tester (fio) tests or suite, to check etcd disk performance in {product-title}.
Original: You should only use the `fio` test to measure disk latency at a specific point in time. This test does not account for long-term disk behavior and other disk workloads that occur with etcd in a production environment.
Revised: Use only the `fio` test to measure disk latency at a specific point in time. This test does not account for long-term disk behavior and other disk workloads that occur with etcd in a production environment.
Original: When you use cluster deployments that span many data centers that are using disks for etcd that do not meet the suggested latency, it increases the chances of service-affecting failures and dramatically reduces the network latency that the control plane can sustain.
Revised: When your cluster deployments span many data centers that are using disks for etcd that do not meet the suggested latency, service-affecting failures can occur. In addition, the network latency that the control plane can sustain is dramatically reduced.
Original: The value of the heartbeat interval should be around the maximum of the average round-trip time (RTT) between members, normally around 1.5x the round-trip time. With the {product-title} default heartbeat interval of 100ms, the suggested RTT between control plane nodes is less than 33 ms with a maximum of less than 66 ms (66 ms x 1.5 = 99 ms). Any network latency that is larger might cause service-affecting events and cluster instability.
Revised: The value of the heartbeat interval should be approximately the maximum of the average round-trip time (RTT) between members, normally around 1.5 times the round-trip time. With the {product-title} default heartbeat interval of 100 ms, the suggested RTT between control plane nodes is less than 33 ms, with a maximum of less than 66 ms (66 ms x 1.5 = 99 ms). Any network latency that is larger might cause service-affecting events and cluster instability.
Original: Consider network latency with network jitter for exact calculations. Network jitter is the variance in network latency or the variation in the delay of received packets. In efficient network conditions, the jitter should be zero. Network jitter affects the network latency calculations for etcd because the actual network latency over time will be the RTT plus or minus Jitter. For example, a network with a maximum latency of 80 ms and jitter of 30 ms will experience latencies of 110 ms, which means etcd will miss heartbeats. This condition results in request timeouts and temporary leader loss. During a leader loss and re-election, the Kubernetes API cannot process any request that causes a service-affecting event and instability of the cluster.
Revised: Consider network latency with network jitter for exact calculations. _Network jitter_ is the variance in network latency or the variation in the delay of received packets. In efficient network conditions, the jitter should be zero. Network jitter affects the network latency calculations for etcd because the actual network latency over time will be the RTT plus or minus Jitter.

For example, a network with a maximum latency of 80 ms and jitter of 30 ms will experience latencies of 110 ms, which means etcd will miss heartbeats. This condition results in request timeouts and temporary leader loss. During a leader loss and re-election, the Kubernetes API cannot process any request that causes a service-affecting event and instability of the cluster.
Original: etcd-m0   4/4     Running   4          22h
Revised: The second example of the effect of database size on etcd synchronization is that if there is a change of 10% of the etcd database during disconnection of one of the control plane nodes, the sync needs to transfer at least 100 MB. Transferring 100 MB over a 1 Gbps link takes 800 ms. On clusters with regular transactions with the Kubernetes API, the larger the etcd database size, the more network instabilities can cause control plane instabilities.
Original: The Kubernetes API transaction rate that is possible when you are using stretched control plane is dependent on the characteristics of the particular deployment. It depends on the combination of the etcd disk latency, the etcd round trip time, and the size of objects that are written to the API. As a result, when you use stretched control planes, the cluster administrators should test the environment to determine the sustained transaction rate that is possible for their environment. The `kube-burner` tool can be used for this purpose.
Revised: When you are using a stretched control plane, the Kubernetes API transaction rate depends on the characteristics of the particular deployment. It depends on the combination of the etcd disk latency, the etcd round trip time, and the size of objects that are written to the API. As a result, when you use stretched control planes, the cluster administrators need to test the environment to determine the sustained transaction rate that is possible for their environment. The `kube-burner` tool can be used for this purpose.
Original: When an etcd client such as `kube-apiserver` connects to an etcd member that is requesting an action that requires a quorum, such as writing a value, if the etcd member is a follower, it returns a message indicating that the transaction should go to the leader. 
Revised: When an etcd client such as `kube-apiserver` connects to an etcd member that is requesting an action that requires a quorum, such as writing a value, if the etcd member is a follower, it returns a message indicating that the transaction needs to go to the leader.
Original:  Use only the `fio` test to measure disk latency at a specific point in time. This test does not account for long-term disk behavior and other disk workloads that occur with etcd in a production environment.
Revised: Use only the `fio` test to measure disk latency at a specific point in time. This test does not account for long-term disk behavior and other disk workloads that occur with etcd in a production environment.
Original: * Previously, a race condition in the hostname that handled the code caused inconsistencies between the boot and machine hostnames. With this release, the race condition is resolved, which ensures consistent hostnames in the Ignition configuration file during the operating system installation. (link:https://issues.redhat.com/browse/OCPBUGS-55680[OCPBUGS-55680]). 
Revised: * Previously, a race condition caused inconsistencies between the node and machine hostnames. With this release, the race condition is resolved, which ensures consistent hostnames in the Ignition configuration file during installation. (link:https://issues.redhat.com/browse/OCPBUGS-55680[OCPBUGS-55680]).