gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: For some configuration items, using a static default for installation is not ideal. Beginning with {product-title-short} version 4.8, the Operator can add annotations that are attached to the CR that you apply to clusters. These annotations allow a default decision that the Operator previously made to persist and be reapplied in the future, even if the default behavior for a fresh installation has changed. In summary, {product-title-short} uses annotations to persist runtime defaults. This means that the default value for a certain configuration setting is decided by the Operator at runtime.
Revised: For some configuration items, using a static default value for the installation is not ideal. Beginning with {product-title-short} version 4.8, the Operator can add annotations that are attached to the CR that you apply to clusters. These annotations allow a default decision that the Operator previously made to persist and be reapplied in the future, even if the default behavior for a fresh installation has changed. In summary, {product-title-short} uses annotations to persist runtime defaults. This means that the default value for a certain configuration setting is decided by the Operator at runtime.
Original: You can configure these features with xref:../machine_management/creating_machinesets/creating-machineset-aws.html#machineset-capacity-reservation_creating-machineset-aws[compute] and xref:../machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-aws.html#machineset-capacity-reservation_cpmso-config-options-aws[control plane] machine sets.
Revised: You can configure these features with xref:../machine_management/creating_machinesets/creating-machineset-aws.adoc#machineset-capacity-reservation_creating-machineset-aws[compute] and xref:../machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-aws.adoc#machineset-capacity-reservation_cpmso-config-options-aws[control plane] machine sets.
Original: This capability is available for xref:../machine_management/creating_machinesets/creating-machineset-vsphere.html#machineset-vsphere-data-disks_creating-machineset-vsphere[compute] and xref:../machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-vsphere.html#machineset-vsphere-data-disks_cpmso-config-options-vsphere[control plane] machine sets.
Revised: This capability is available for xref:../machine_management/creating_machinesets/creating-machineset-vsphere.adoc#machineset-vsphere-data-disks_creating-machineset-vsphere[compute] and xref:../machine_management/control_plane_machine_management/cpmso_provider_configurations/cpmso-config-options-vsphere.adoc#machineset-vsphere-data-disks_cpmso-config-options-vsphere[control plane] machine sets.
Original: You can use the Cluster API to perform worker node provisioning management actions after the cluster installation finishes. The Cluster API allows dynamic management of worker node machine sets and machines. However, there is no support for control plane machines.
Revised: You can use the Cluster API to perform compute node provisioning management actions after the cluster installation finishes. The Cluster API allows dynamic management of compute node machine sets and machines. However, there is no support for control plane machines.
Original: * You can now xref:../../virt/managing_vms/virt-manage-vmis.adoc#virt-searching-vmis-web_virt-manage-vmis[search for virtual machines] by name, project, description, labels, date created, vCPU, memory, and more. You can also save frequently used search queries.
Revised: * You can now xref:../../virt/managing_vms/virt-manage-vmis.adoc#virt-searching-vmis-web_virt-manage-vmis[search for virtual machines] by fields such as name, project, description, labels, date created, vCPU, and  memory. You can also save frequently used search queries.
Original: Deprecated functionality is still included in {product-title} and continues to be supported; however, it will be removed in a future release of this product and is not recommended for new deployments. For the most recent list of major functionality deprecated and removed within {product-title} {product-version}, refer to the table below. Additional details for more functionality that has been deprecated and removed are listed after the table.
Revised: With this release, you can now allocate load balancers to customize deployments. This feature ensures optimal traffic distribution, high application availability, uninterrupted service, and network segmentation.
Original: [id="ocp-4-19-networking-allocate-load-balancers-to-specific-subnets_{context}"]
==== Allocate API and ingress load balancers to specific subnets
With this release, you can now allocate load balancers to customize deployments on AWS only. This feature ensures optimal traffic distribution, high application availability, uninterrupted service, and network segmentation.
Revised: [id="ocp-4-19-networking-allocate-load-balancers-to-specific-subnets_{context}"]
==== Allocate API and ingress load balancers to specific subnets on AWS
With this release, you can now allocate load balancers to customize deployments when installing an OpenShift Container Platform cluster on AWS. This feature ensures optimal traffic distribution, high application availability, uninterrupted service, and network segmentation.
Original: With this release, you can now allocate load balancers to customize deployments when installing an OpenShift Container Platform cluster on AWS. This feature ensures optimal traffic distribution, high application availability, uninterrupted service, and network segmentation.
Revised: With this release, you can now allocate load balancers to customize deployments when installing an {product-title} cluster on AWS. This feature ensures optimal traffic distribution, high application availability, uninterrupted service, and network segmentation.
Original: For more information, see xref.../installing/installing_aws/installation-config-parameters-aws#installation-configuration-parameters-network_installation-config-parameters-aws and xref.../networking/configuring_ingress_cluster_traffic/allocating-load-balancers.adoc
Revised: For more information, see xref.../installing/installing_aws/installation-config-parameters-aws#installation-configuration-parameters-network_installation-config-parameters-aws and xref.../networking/configuring_ingress_cluster_traffic/allocating-load-balancers.adoc#allocating-load-balancers[Allocating load balancers to specific subnets]
Original: For more information, see xref:.../installing/installing_aws/installation-config-parameters-aws.adoc#installation-configuration-parameters-network_installation-config-parameters-aws[Installation configuration parameters on AWS] and xref:../networking/configuring_ingress_cluster_traffic/allocating-load-balancers.adoc#allocating-load-balancers[Allocating load balancers to specific subnets].
Revised: For more information, see xref:../installing/installing_aws/installation-config-parameters-aws.adoc#installation-configuration-parameters-network_installation-config-parameters-aws[Installation configuration parameters on AWS] and xref:../networking/configuring_ingress_cluster_traffic/allocating-load-balancers.adoc#allocating-load-balancers[Allocating load balancers to specific subnets].
Original: You can use a lightweight version of OpenShift GitOps with {microshift-short} to help manage your applications. Install the necessary Argo CD manifests using an RPM package. This RPM package included the necessary manifests that runs core Argo CD.
Revised: You can use a lightweight version of OpenShift GitOps with {microshift-short} to manage your applications by installing the `microshift-gitops` RPM package. The `microshift-gitops` RPM package includes the  manifests required to run core Argo CD.
Original: You can use a lightweight version of OpenShift GitOps with {microshift-short} to help manage your applications. Install the necessary Argo CD manifests using an RPM package. This RPM package included the necessary manifests that runs core Argo CD.
This process installs the basic GitOps functionalities. The Argo CD CLI is not available on {microshift-short}.
* Additional RAM storage of 250MB recommended
Revised: * You configured 250MB of additional RAM
Original: You can use a lightweight version of OpenShift GitOps with {microshift-short} to help manage your applications. Install the necessary Argo CD manifests using an RPM package. This RPM package included the necessary manifests that runs core Argo CD.
This process installs the basic GitOps functionalities. The Argo CD CLI is not available on {microshift-short}.
* Additional RAM storage of 250MB recommended
Revised: . Enable the GitOps repository with the subscription manager by running the following command:
Original: * When you enable external IP collection for a cluster, Collector in those clusters report more information to Sensor and to Central. This might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. It is recommended that you do not enable this feature on clusters with communication patterns involving more than 10,000 distinct external entities.
Revised: * When you enable external IP collection for a cluster, Collector in those clusters report more information to Sensor and to Central. This might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. It is recommended that you do not enable this feature on clusters with communication patterns involving more than 10,000 distinct external entities. However, if the pattern is mostly ingres or egress, then enabling external IPs only xref:../operating/using-collector-runtime-configuration.adoc#using-collector-runtime-configuration[in the opposite direction] makes it possible to overcome the scaling issue. In a test in which 20 flows involving external entities were created per second, Central memory growth was 450 MB per day. This memory persisted even when associated deployments were deleted. Disabling external IPs at the Collector level stops the growth of memory usage in Central due to external IPs. Disabling external IPs at the Central level by setting `ROX_EXTERNAL_IPS` to false and setting `ROX_EXTERNAL_IPS_PRUNING` to true clears out almost all memory used by external IPs.
Original: * When you enable external IP collection for a cluster, Collector in those clusters report more information to Sensor and to Central. This might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. It is recommended that you do not enable this feature on clusters with communication patterns involving more than 10,000 distinct external entities.
* When you enable external IP collection, external IP addresses might appear in a deployment's network baseline.
Revised: * When you enable external IP collection for a cluster, the Collector in those clusters reports more information to Sensor and Central. By enabling external IP collection for a cluster, you might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. Red{nbsp}Hat recommends turning off this feature on clusters with communication patterns involving more than 10,000 distinct external entities. However, if the pattern is mostly ingress or egress, then enabling external IPs only in the opposite direction makes it possible to overcome the scaling issue. For more information, see "Using collector runtime configuration" in the Additional resources section.
Original: * When you enable external IP collection for a cluster, Collector in those clusters report more information to Sensor and to Central. This might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. It is recommended that you do not enable this feature on clusters with communication patterns involving more than 10,000 distinct external entities.
* When you enable external IP collection, external IP addresses might appear in a deployment's network baseline.
Revised: * When you enable external IP collection for a cluster, the Collector in those clusters reports more information to Sensor and Central. Doing this might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. Red{nbsp}Hat recommends that you turn off this feature on clusters with communication patterns involving more than 10,000 distinct external entities. However, if the pattern is mostly ingress or egress, you can overcome the scaling issue by enabling external IPs only in the opposite direction. For more information, see "Using collector runtime configuration" in the Additional resources section.
Original: * When you enable external IP collection for a cluster, Collector in those clusters report more information to Sensor and to Central. This might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. It is recommended that you do not enable this feature on clusters with communication patterns involving more than 10,000 distinct external entities.
* When you enable external IP collection, external IP addresses might appear in a deployment's network baseline.
Revised: During a test, Red{nbsp}Hat generated 20 flows per second with external entities, leading to a daily increase of 450 MB in central memory usage. This memory persisted even after deleting the deployments. Turning off external IPs at the Collector level stops further memory growth in Central instances/Central logs that are caused by external IPs. To clear most of the memory that external IPs use , turn off external IPs at the Central level. To do this, set `ROX_EXTERNAL_IPS` to `false` and `ROX_EXTERNAL_IPS_PRUNING` to `true`.
Original: * When you enable external IP collection for a cluster, Collector in those clusters report more information to Sensor and to Central. This might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. It is recommended that you do not enable this feature on clusters with communication patterns involving more than 10,000 distinct external entities.
* When you enable external IP collection, external IP addresses might appear in a deployment's network baseline.
Revised: * When you enable external IP collection for a cluster, the Collector in those clusters reports more information to Sensor and Central. Doing this might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. Red{nbsp}Hat recommends turning off this feature on clusters with communication patterns involving more than 10,000 distinct external entities. However, if the pattern is mostly ingress or egress, then enabling external IPs only in the opposite direction makes it possible to overcome the scaling issue. For more information, see "Using the Collector runtime configuration" in the Additional resources section.
Original: include::snippets/technology-preview.adoc[]
Revised: You can use the Collector runtime configuration to modify some collector behaviors without restarting the Collector. To set the Collector runtime configuration, use the `collector-config` object in `ConfigMap` . When you create or update the `ConfigMap` object, Collector refreshes the runtime configuration. When you delete the `ConfigMap` object, the settings revert to the default runtime configuration values.
Original: include::snippets/technology-preview.adoc[]
Currently, only two settings are controlled by using Collector runtime configuration:
Revised: * `networking.externalIps.direction` specifies the direction for collecting external IPs. The values are `INGRESS`, `EGRESS`, or `BOTH` (default). For example, when you select `EGRESS` it provides details for all outgoing connections while aggregating the incoming ones.
Original: * When you enable external IP collection for a cluster, Collector in those clusters report more information to Sensor and to Central. This might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. It is recommended that you do not enable this feature on clusters with communication patterns involving more than 10,000 distinct external entities.
* When you enable external IP collection, external IP addresses might appear in a deployment's network baseline.
Revised: * When you enable external IP collection for a cluster, the Collector in those clusters reports more information to Sensor and Central. Enabling external IP collection might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. Red{nbsp}Hat recommends turning off this feature on clusters with communication patterns involving more than 10,000 distinct external entities. However, if the pattern is mostly ingress or egress, then enabling external IPs only in the opposite direction makes it possible to overcome the scaling issue. For more information, see "Using collector runtime configuration" in the Additional resources section.
Original: * When you enable external IP collection for a cluster, Collector in those clusters report more information to Sensor and to Central. This might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. It is recommended that you do not enable this feature on clusters with communication patterns involving more than 10,000 distinct external entities.
* When you enable external IP collection, external IP addresses might appear in a deployment's network baseline.
Revised: During a test, Red{nbsp}Hat generated 20 flows per second with external entities, leading to a daily increase of 450 MB in central memory usage. This memory persisted even after deleting the deployments. Turning off external IPs at the Collector level stops further memory growth in Central caused by external IPs. To clear most of the memory used by external IPs, turn off external IPs at the Central level by setting the `ROX_EXTERNAL_IPS` parameter to `false` and the `ROX_EXTERNAL_IPS_PRUNING` parameter to `true`.
Original: include::snippets/technology-preview.adoc[]
You can view external entities in the Network Graph by selecting the External Entities graph node or query external entities by using the API.
Visualizing external entities is an opt-in feature that is disabled by default. To enable this feature, you must enable external IP collection in Central and secured clusters, as described in the following sections.
include::modules/enabling-external-ip-collection-central.adoc[leveloffset=+1]

Revised: [role="_additional-resources"]
[id="additional-resources_{context}"]
== Additional resources
Original: * When you enable external IP collection for a cluster, Collector in those clusters report more information to Sensor and to Central. This might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. It is recommended that you do not enable this feature on clusters with communication patterns involving more than 10,000 distinct external entities.
* When you enable external IP collection, external IP addresses might appear in a deployment's network baseline.
Revised: * When you enable external IP collection for a cluster, the Collector in those clusters reports more information to Sensor and Central. Enabling external IP collection might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. Red{nbsp}Hat recommends that you turn off this feature on clusters with communication patterns involving more than 10,000 distinct external entities. However, if the pattern is mostly ingress or egress, you can overcome the scaling issue by enabling external IPs only in the opposite direction. For more information, see "Using Collector runtime configuration" in the Additional resources section.
Original: * When you enable external IP collection for a cluster, Collector in those clusters report more information to Sensor and to Central. This might create scalability issues if the workload in the cluster communicates with a large number of distinct external peers. It is recommended that you do not enable this feature on clusters with communication patterns involving more than 10,000 distinct external entities.
* When you enable external IP collection, external IP addresses might appear in a deployment's network baseline.
Revised: During a test, Red{nbsp}Hat generated 20 flows per second with external entities, leading to a daily increase of 450 MB in Central memory usage. This memory persisted even after deleting the deployments. Turning off external IPs at the Collector level stops further memory growth in Central caused by external IPs. To clear most of the memory used by external IPs, turn off external IPs at the Central level by setting the `ROX_EXTERNAL_IPS` environment variable to `false` and the `ROX_EXTERNAL_IPS_PRUNING` environment variable to `true`.
Original: * Currently, pods that use a `guaranteed` QoS class and request whole CPUs might not restart automatically after a node reboot or kubelet restart. The issue might occur in nodes configured with a static CPU Manager policy and using the `full-pcpus-only` specification, and when most or all CPUs on the node are already allocated by such workloads. As a workaround, manually delete and recreate the affected pods. (link:https://issues.redhat.com/browse/OCPBUGS-43280[*OCPBUGS-43280*])
Revised: * Currently, pods that use a `guaranteed` QoS class and request whole CPUs might not restart automatically after a node reboot or kubelet restart. The issue might occur in nodes configured with a static CPU Manager policy and using the `full-pcpus-only` specification, and when most or all CPUs on the node are already allocated by such workloads. As a workaround, manually delete and re-create the affected pods. (link:https://issues.redhat.com/browse/OCPBUGS-43280[*OCPBUGS-43280*])
Original: * Previously, the `disk2mirror` process did not display logs during the cache registry population, which caused an incomplete process. With this release, the working and cache directories are verified before adding the  extracted mirror archives. This update improves visibility during the `disk2mirror` process and reduces user uncertainty about an incomplete process. (link:https://issues.redhat.com/browse/OCPBUGS-56659[OCPBUGS-56659])
Revised: * Previously, the `disk2mirror` process did not display logs during the cache registry population, which caused an incomplete process. With this release, the working and cache directories are verified before adding the extracted mirror archives. This update improves visibility during the `disk2mirror` process and reduces user uncertainty about an incomplete process. (link:https://issues.redhat.com/browse/OCPBUGS-56659[OCPBUGS-56659])
Original: * By using the OpenShift Container Platform web console, you can now xref:../../virt/managing_vms/virt-migrating-vms-in-single-cluster-to-different-storage-class.adoc#virt-migrating-bulk-vms-different-storage-class-web_virt-migrating-vms-in-single-cluster-to-different-storage-class[migrate single-cluster VMs in bulk from one storage class to another storage class].
Revised: * By using the OpenShift Container Platform web console, you can now xref:../../virt/managing_vms/virt-migrating-vms-in-single-cluster-to-different-storage-class.adoc#virt-migrating-bulk-vms-different-storage-class-web_virt-migrating-vms-in-single-cluster-to-different-storage-class[migrate VMs in bulk from one storage class to another storage class].