gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: With this release, you can enable user-provisioned DNS instead of the default cluster-provisioned DNS solution. For example, your organization's security policies might not allow the use of public DNS services such as Google Cloud DNS. You can manage your DNS only for the IP addresses of the API and Ingress servers. If you use this feature, you must provide your own DNS solution that includes records for `api.<cluster_name>.<base_domain>.` and `*.apps.<cluster_name>.<base_domain>.`.
Revised: With this release, you can enable user-provisioned domain name server (DNS) instead of the default cluster-provisioned DNS solution. For example, your organization's security policies might not allow the use of public DNS services such as Google Cloud DNS. You can manage your DNS only for the IP addresses of the API and Ingress servers. If you use this feature, you must provide your own DNS solution that includes records for `api.<cluster_name>.<base_domain>.` and `*.apps.<cluster_name>.<base_domain>.`.
Original: The {istio} CNI update process uses in-place updates. When the `IstioCNI` resource changes, the daemonset automatically replaces the existing `istio-cni-node` pods with the specified version of the CNI plugin.
Revised: The {istio} Container Network Interface (CNI) update process uses in-place updates. When the `IstioCNI` resource changes, the daemonset automatically replaces the existing `istio-cni-node` pods with the specified version of the CNI plugin.
Original: `spec.version`:: defines the CNI plugin version to install. Specify the value in the format `vX.Y.Z`, where `X.Y.Z` represents the desired version. For example, use `v1.24.4` to install CNI plugin version `1.24.4`.
Revised: `spec.version`:: defines the CNI plugin version to install. Specify the value in the format `vX.Y.Z`, where `X.Y.Z` represents the desired version. For example, use `v1.24.4` to install the CNI plugin version `1.24.4`.
Original: ** If the namespace _has_ the label, and a primary `ClusterUserDefinedNetwork` CR does not exist, a pod in the namespace is not created until the `ClusterUserDefinedNetwork` CR is created.
Revised: ** You must make sure that the `spec.network.physicalNetworkName` field matches the field that you configured in the OVS bridge mapping when you create your CUDN. This ensures that you are bridging to the intended segment of your physical network. Do not reuse the same `physicalNetworkName` for different physical networks.
Original: ** If the namespace _has_ the label, and a primary `ClusterUserDefinedNetwork` CR does not exist, a pod in the namespace is not created until the `ClusterUserDefinedNetwork` CR is created.
Revised: ** When you configure a Virtual Local Area Network (VLAN), you must ensure that both your underlying physical infrastructure (switches, routers, and so on) and your nodes are properly configured to accept VLAN IDs (VIDs). This means that you configure the physical network interface, for example `eth1`, as an access port for the VLAN, for example 20, that you are connecting to through the physical switch. In addition, you must verify that an OVS bridge mapping, for example `eth1`, exists on your nodes to ensure that that the physical interface is properly connected with OVN-Kubernetes.
Original: ** If the namespace _has_ the label, and a primary `ClusterUserDefinedNetwork` CR does not exist, a pod in the namespace is not created until the `ClusterUserDefinedNetwork` CR is created.
Revised: ** You must make sure that the `spec.network.physicalNetworkName` field matches the field that you configured in the OVS bridge mapping when you create your CUDN. This ensures that you are bridging to the intended segment of your physical network. Do not reuse the same `physicalNetworkName` value for different physical networks.
Original: ** If the namespace _has_ the label, and a primary `ClusterUserDefinedNetwork` CR does not exist, a pod in the namespace is not created until the `ClusterUserDefinedNetwork` CR is created.
Revised: ** When you configure a Virtual Local Area Network (VLAN), you must ensure that both your underlying physical infrastructure (switches, routers, and so on) and your nodes are properly configured to accept VLAN IDs (VIDs). This means that you configure the physical network interface, for example `eth1`, as an access port for the VLAN, for example `20`, that you are connecting to through the physical switch. In addition, you must verify that an OVS bridge mapping, for example `eth1`, exists on your nodes to ensure that that the physical interface is properly connected with OVN-Kubernetes.
Original: // Module included in the following assemblies:
//
// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc

Telco core clusters support large scale telco applications including control plane functions such as signaling, aggregation, and session border controller (SBC); and centralized data plane functions such as 5G user plane functions (UPF).
Revised: Telco core clusters support large scale telco applications including control plane functions like signaling, aggregation, session border controller (SBC), and centralized data plane functions such as 5G user plane functions (UPF).
Original: // Module included in the following assemblies:
//
// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc

= Agent-based Installer
* No reference design updates in this release
+
--
Telco core clusters can be installed by using the Agent-based Installer.
This method allows you to install OpenShift on bare-metal servers without requiring additional servers or VMs for managing the installation.
Installation progress can be monitored using the ABI tool from any system with network connectivity to the supervisor node's API interfaces.
ABI supports the following:
* Installation with no additional supporting install or bastion servers required to complete the installation
--
Revised: * Installation without the use of additional servers to support installation, for example, the bastion node.
Original: // Module included in the following assemblies:
//
// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc

= Agent-based Installer
* No reference design updates in this release
+
--
Telco core clusters can be installed by using the Agent-based Installer.
This method allows you to install OpenShift on bare-metal servers without requiring additional servers or VMs for managing the installation.
Installation progress can be monitored using the ABI tool from any system with network connectivity to the supervisor node's API interfaces.
ABI supports the following:
* Installation with no additional supporting install or bastion servers required to complete the installation
--
* Disconnected installation requires a registry that is reachable from the installed host, with all required content mirrored in that registry.
Revised: * Disconnected installation requires a registry with all required content mirrored and reachable from the installed host.
Original: // Module included in the following assemblies:
//
// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc

= Agent-based Installer
* No reference design updates in this release
+
--
Telco core clusters can be installed by using the Agent-based Installer.
This method allows you to install OpenShift on bare-metal servers without requiring additional servers or VMs for managing the installation.
Installation progress can be monitored using the ABI tool from any system with network connectivity to the supervisor node's API interfaces.
ABI supports the following:
* Installation with no additional supporting install or bastion servers required to complete the installation
--
* Disconnected installation requires a registry that is reachable from the installed host, with all required content mirrored in that registry.
* Networking configuration should be applied as NMState configuration during installation.
Day 2 networking configuration using the NMState Operator is not supported.
Revised: * Networking configuration should be applied as an NMState configuration during installation .

* A Day 2 configuration using the NMState Operator is not supported.
Original: 
include::snippets/nodes-cgroup-vi-removed.adoc[]

* The minimum reserved capacity (`systemReserved`) required can be found by following the guidance in the link:https://access.redhat.com/solutions/5843241[Which amount of CPU and memory are recommended to reserve for the system in OpenShift 4 nodes?] Knowledgebase article.
Revised: * The minimum reserved capacity (`systemReserved`) required can be found by following the guidance in the Red Hat Knowledgebase solution link:https://access.redhat.com/solutions/5843241[Which amount of CPU and memory are recommended to reserve for the system in OCP 4 nodes?].
Original: include::snippets/nodes-cgroup-vi-removed.adoc[]

Revised: * As of {product-title} 4.19, cgroup v1 is no longer supported and has been removed. All workloads must now be compatible with cgroup v2. For more information, see link:https://www.redhat.com/en/blog/rhel-9-changes-context-red-hat-openshift-workloads[Red Hat Enterprise Linux 9 changes in the context of Red Hat OpenShift workloads] (Red Hat Knowledgebase).
Original: Telco core clusters can use MachineConfigPools (MCPs) to split worker nodes into additional separate roles, for example, due to different hardware profiles.
Revised: Telco core clusters can use MCPs to split worker nodes into additional separate roles, for example, due to different hardware profiles. This allows custom tuning for each role and also plays a critical function in speeding up a telco core cluster deployment or upgrade. More importantly, multiple MCPs allow you to properly plan cluster upgrades across one or many maintenance windows. This is crucial because telco-grade services may otherwise be affected if careful planning is not considered.
Original: // Module included in the following assemblies:
//
// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc

* No reference design updates in this release
+
--
{product-title} supports an opt-in Dedicated Service Monitor feature that creates an additional set of pod CPU and memory metrics that do not suffer from this behavior.
For more information, see link:https://access.redhat.com/solutions/7012719[Dedicated Service Monitors - Questions and Answers (Red Hat Knowledgebase)].
Revised: For more information, see the Red Hat Knowledgebase solution link:https://access.redhat.com/solutions/7012719[Dedicated Service Monitors - Questions and Answers].
Original: // Module included in the following assemblies:
//
// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc

* No reference design updates in this release
+
--
The scheduler is a cluster-wide component responsible for selecting the correct node for a given workload.
However, a few specific use cases are described in the following section.
Revised: However, there are a few specific use cases described in the following section.
Original: // Module included in the following assemblies:
//
// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc

* No reference design updates in this release
+
--
The scheduler is a cluster-wide component responsible for selecting the correct node for a given workload.
However, a few specific use cases are described in the following section.
--
This might cause workloads to be rejected when scheduled to a node with the topology manager policy set to `single-numa-node` or `restricted`.
For more information, see "Topology Manager policies".
** For example, consider a pod requesting 6 CPUs that is scheduled to an empty node that has 4 CPUs per NUMA node.
Revised: For example, consider a pod requesting 6 CPUs and being scheduled to an empty node that has 4 CPUs per NUMA node.
Original: // Module included in the following assemblies:
//
// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc

// https://issues.redhat.com/browse/CNF-13768
* link:https://access.redhat.com/articles/7090422[New knowledgebase article on creating custom node firewall rules]
+
--
Use the following security-oriented features and configurations to secure your clusters:
With this feature, a conformant DPDK pod can run without requiring root privileges.
Refer to link:https://access.redhat.com/articles/7090422[Custom nftable firewall rules in OpenShift] for a supported method of implementing custom nftables firewall rules in OpenShift cluster nodes.
This article is intended for cluster administrators who are responsible for managing network security policies in OpenShift environments.
Revised: See the Red Hat Knowledgebase solution article link:https://access.redhat.com/articles/7090422[Custom nftable firewall rules in OpenShift] for a supported method for implementing custom nftables firewall rules in {product-title} cluster nodes.
Original: For Mellanox NICs, you must disable the Mellanox vendor plugin in the SR-IOV Network Operator.
See "Configuring an SR-IOV network device" for more information.
Revised: For Mellanox NICs, you must disable the Mellanox vendor plugin in the SR-IOV Network Operator. For more information see, "Configuring an SR-IOV network device" for more information.
Original: {product-title}'s Bare Metal as a Service (BMaaS) feature enables you to provision and manage bare-metal hosts by using the Metal^3^ API. These hosts, external to the {product-title} cluster, can run workloads that might not be suitable for containerisation or virtualisation, such as applications requiring direct hardware access, high-performance computing tasks or legacy applications. BMaaS provides the following capabilities:
Revised: The Bare Metal as a Service (BMaaS) feature for {product-title} enables you to provision and manage bare-metal hosts by using the Metal^3^ API. These hosts, external to the {product-title} cluster, can run workloads that might not be suitable for containerization or virtualization. For example, workloads such as applications that require direct hardware access, conduct high-performance computing tasks or are legacy applications. BMaaS has the following capabilities:
Original: To allow the Bare Metal Operator (BMO) to manage `BareMetalHost` resources across all namespaces in your {product-title} cluster, you must configure it to watch all namespaces. This configuration is important to avoid mixing non-{product-title} workloads with OpenShift components in the same namespace.
Revised: For the Bare Metal Operator (BMO) to manage `BareMetalHost` resources across all namespaces in your {product-title} cluster, you must configure the Operator to watch all namespaces. This configuration is important to avoid mixing non-{product-title} workloads with other components in the same namespace.
Original:   All bare-metal hosts must use a Baseboard Management Controller (BMC) configured with the Redfish protocol and virtual media (`redfish-virtualmedia`) driver. Each bare-metal host requires a boot interface with a MAC address configured to receive an IP address lease.
Revised: All bare-metal hosts must use a Baseboard Management Controller (BMC) configured with the Redfish protocol and virtual media (`redfish-virtualmedia`) driver. Each bare-metal host requires a boot interface with a MAC address configured to receive an IP address lease.
Original:   A DHCP server, separate from the {product-title} and Metal^3^ infrastructure, must be operational on the same Layer 2 network as the bare-metal hosts. The DHCP server must be configured to match the MAC addresses of the boot interfaces on the bare-metal hosts, enabling IP address assignment for communication with Metal^3^ components.
Revised: A DHCP server, separate from the {product-title} and Metal^3^ infrastructure, must be operational on the same Layer 2 network as the bare-metal hosts. The DHCP server must be configured to match the MAC addresses of the boot interfaces on the bare-metal hosts, enabling IP address assignment for communication with Metal^3^ components.
Original:   BMaaS does not provide images for deployment on hardware. You must configure a web server with the images and checksums you want to use. The `image` field of the `BareMetalHost` (BMH) spec references these images during deployment. Ensure the bare-metal hosts can reach the web server's URL. Here is an example of an image and checksum you might include:
Revised: BMaaS does not provide images for deployment on hardware. You must configure a web server with the images and checksums you want to use. The `image` field of the `BareMetalHost` spec references these images during deployment. Ensure that the bare-metal hosts can reach the web server URL. The following is an example of an image and checksum you might include:
Original: As standalone systems, these hosts operate independently of the {product-title} cluster and support diverse workloads by integrating bare-metal resources with containerized and virtualized applications. BMaaS can run other operating systems, but only {op-system-base-full} and CentOS Stream 9 underwent testing.
Revised: As standalone systems, these hosts operate independently of the {product-title} cluster and support diverse workloads by integrating bare-metal resources with containerized and virtualized applications. BMaaS can run other operating systems, but only {op-system-base-full} and CentOS Stream 9 were tested.
Original: The `userData` field in the `BareMetalHost` custom resource allows you to customize the bare-metal host during provisioning by providing initial configuration data, such as user credentials or system settings. For most operating systems, this is achieved by using a `cloud-init` script encapsulated in a Kubernetes secret.
Revised: Customize the bare-metal host during provisioning by providing initial configuration data in the form of a script by using the `userData` field in the `BareMetalHost` custom resource (CR). For example, you can provide user credentials and system settings. For most operating systems, this is achieved by using a `cloud-init` script encapsulated in a Kubernetes secret. The `cloud-init` service can read the custom scripts that you create in the `userData` format.
Original: . Create a BMaaS `bmadmin` user with the cluster's identity provider. For example, when using the `htpasswd` identify provider, run the following command:
+
[source,terminal]
----
$ htpasswd -c -B -b ./users.htpasswd <username> <password>
----
<username>::
  The `htpasswd` user name. Replace `<bmadmin>` with your username.
Revised: . Create a BMaaS user with the cluster's identity provider. For example, when using the `htpasswd` identify provider, run the following command:

[source,terminal]
$ htpasswd -c -B -b ./users.htpasswd <username> <password>
<username>::
The `htpasswd` user name. Replace `<username>` with your username. eg. `bmadmin` / For example we will use `bmadmin`
Original: |Defines a list of existing subnets to be used in place of automatically generated subnets. You specify a subnet by providing the subnet ID and a list of roles that apply to that subnet. If you specify subnet IDs but do not specify roles for any subnet, the subnets' roles will be decided automatically. If you do not specify any roles, you must ensure that any other subnets in your VPC have the `kubernetes.io/cluster/<cluster-id>` or `kubernetes.io/cluster/unmanaged: true` tags, or the installation will fail.
Revised: |A list of subnets in an existing VPC to be used in place of automatically created subnets. You specify a subnet by providing the subnet ID and an optional list of roles that apply to that subnet. If you specify subnet IDs but do not specify roles for any subnet, the subnets' roles will be decided automatically. If you do not specify any roles, you must ensure that any other subnets in your VPC have the `kubernetes.io/cluster/.*: .*` or `kubernetes.io/cluster/unmanaged: true` tags.

The subnets must be part of the same `machineNetwork[].cidr` ranges that you specify.

For a standard cluster, specify a public and a private subnet for each availability zone.

For a private cluster, specify a private subnet for each availability zone.

For clusters that use AWS Local Zones, you must add AWS Local Zone subnets to this list to ensure edge machine pool creation.
Original: |One or more roles that apply to the subnet specified by `platform.aws.vpc.subnets.id`. If you specify a role for any subnet, each subnet must have at least one assigned role, and the "ClusterNode", "IngressControllerLB", "ControlPlaneExternalLB", and "ControlPlaneInternalLB" roles must be assigned to at least one subnet. However, if the cluster scope is internal, then the "ControlPlaneExternalLB" role is not required.
Revised: |One or more roles that apply to the subnet specified by `platform.aws.vpc.subnets.id`. If you specify a role for any subnet, each subnet must have at least one assigned role, and the `ClusterNode`, `BootstrapNode`, `IngressControllerLB`, `ControlPlaneExternalLB`, and `ControlPlaneInternalLB` roles must be assigned to at least one subnet. However, if the cluster scope is internal, then the `ControlPlaneExternalLB` role is not required.

For subnets in AWS Local Zones, only `EdgeNode` role can be assigned.
Original: |List of one or more role types. Valid values include "ClusterNode", "EdgeNode", "Bootstrap", "IngressControllerLB", "ControlPlaneExternalLB", and "ControlPlaneInternalLB".
Revised: |List of one or more role types. Valid values include `ClusterNode`, `EdgeNode`, `BootstrapNode`, `IngressControllerLB`, `ControlPlaneExternalLB`, and `ControlPlaneInternalLB`.
Original: |One or more roles that apply to the subnet specified by `platform.aws.vpc.subnets.id`. If you specify a role for any subnet, each subnet must have at least one assigned role, and the `ClusterNode`, `IngressControllerLB`, `ControlPlaneExternalLB`, `BootstrapNode` and `ControlPlaneInternalLB` roles must be assigned to at least one subnet. However, if the cluster scope is internal, then the `ControlPlaneExternalLB` role is not required.
Revised: |One or more roles that apply to the subnet specified by `platform.aws.vpc.subnets.id`. If you specify a role for any subnet, each subnet must have at least one assigned role, and the `ClusterNode`, `IngressControllerLB`, `ControlPlaneExternalLB`, `BootstrapNode`, and `ControlPlaneInternalLB` roles must be assigned to at least one subnet. However, if the cluster scope is internal, then the `ControlPlaneExternalLB` role is not required.
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: |`spec.network.<topology>.ipam.mode`
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: |`spec.<topology>.ipam.mode`