gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: include::modules/hcp-ibm-power-create-heterogeneous-nodepools-agent-hc.adoc[leveloffset=+2]

include::modules/hcp-ibm-power-heterogeneous-nodepools-create-agent-cluster.adoc[leveloffset=+2]

include::modules/hcp-create-heterogeneous-nodepools.adoc[leveloffset=+2]

include::modules/hcp-ibm-power-heterogeneous-nodepools-agent-hc-dns.adoc[leveloffset=+2]

include::modules/hcp-create-infraenv.adoc[leveloffset=+2]

include::modules/hcp-adding-agents.adoc[leveloffset=+2]

include::modules/hcp-scale-the-nodepool.adoc[leveloffset=+2]
Revised: include::hcp-ibm-power-create-heterogeneous-nodepools-agent-hc-con.adoc[leveloffset=+1]

include::modules/hcp-ibm-power-create-heterogeneous-nodepools-agent-hc.adoc[leveloffset=+2]

include::modules/hcp-ibm-power-heterogeneous-nodepools-create-agent-cluster.adoc[leveloffset=+2]

include::modules/hcp-create-heterogeneous-nodepools.adoc[leveloffset=+2]

include::modules/hcp-ibm-power-heterogeneous-nodepools-agent-hc-dns.adoc[leveloffset=+2]

include::modules/hcp-create-infraenv.adoc[leveloffset=+2]

include::modules/hcp-adding-agents.adoc[leveloffset=+2]

include::modules/hcp-scale-the-nodepool.adoc[leveloffset=+2]
Revised: [id="hcp-ibm-power-heterogeneous-nodepools"]
== Creating heterogeneous node pools on agent hosted clusters

On the agent platform, you can create heterogeneous node pools so that your clusters can run diverse machine types, such as x86_64 or ppc64le, within a single hosted cluster.

include::modules/hcp-ibm-power-create-heterogeneous-nodepools-agent-hc-con.adoc[leveloffset=+3]
Original: You add agents by manually configuring the machine to boot with a live ISO. You can download the live ISO and use it to boot a bare-metal node or a virtual machine. On boot, the node communicates with the `assisted-service` and registers as an agent in the same namespace as the `infraenv`. When each agent is created, you can optionally set its `installation_disk_id` and `hostname` parameters in the specifications. When you are done, approve it to indicate that the agent is ready for use.
Revised: You add agents by manually configuring the machine to boot with a live ISO. You can download the live ISO and use it to boot a bare-metal node or a virtual machine. On boot, the node communicates with the `assisted-service` and registers as an agent in the same namespace as the `InfraEnv` resource. When each agent is created, you can optionally set its `installation_disk_id` and `hostname` parameters in the specifications. When you are done, approve it to indicate that the agent is ready for use.
Original: For heterogeneous node pools, you must create an `infraenv` custom resource (CR) for each architecture. For example, for node pools with `x86_64` and `ppc64le` architectures, create an `infraenv` CR for `x86_64` and `ppc64le`.
Revised: For heterogeneous node pools, you must create an `InfraEnv` custom resource (CR) for each architecture. For example, for node pools with `x86_64` and `ppc64le` architectures, create an `InfraEnv` CR for `x86_64` and `ppc64le`.
Original: Before proceeding, make sure that the operating system (OS) images for both `x86_64` and `ppc64le` architectures are added to the `AgentServiceConfig` resource. After this, you can use the `infraenv` resources to get the minimal ISO image.
Revised: Before proceeding, make sure that the operating system (OS) images for both `x86_64` and `ppc64le` architectures are added to the `AgentServiceConfig` resource. After this, you can use the `InfraEnv` resources to get the minimal ISO image.
Original: . Optional: If your cluster has problems with the DNS health check probe because of DNS connectivity issues, you can add the following DNS hostname configuration to the `NMState` CRD to build in health checks that can resolve these issues:
+
[source,terminal]
----
apiVersion: nmstate.io/v1
kind: NMState
metadata:
  name: nmstate
spec:
  probeConfiguration:
    dns:
      host: redhat.com
# ...
----
Revised: . If your cluster has problems with the DNS health check probe because of DNS connectivity issues, you can add the following DNS hostname configuration to the `NMState` CRD to build in health checks that can resolve these issues:

[source,yaml]
apiVersion: nmstate.io/v1
kind: NMState
metadata:
name: nmstate
spec:
probeConfiguration:
dns:
host: redhat.com
# ...
Original: A layer 2 topology creates a virtual switch that is distributed across all nodes in a cluster. Virtual machines and pods connect to this virtual switch so that all these components can communicate with each other within the same subnet. If you decide not to specify a layer 2 subnet, then you must manually configure IP addresses for each pod in your cluster. When you do not specify a layer 2 subnet, port security is limited to preventing Media Access Control (MAC) spoofing only, and does not include IP spoofing. A layer 2 topology creates a single broadcast domain that can be challenging in large network environments, where the topology might cause a broadcast storm that can degrade network performance.
The following diagram shows two nodes that use an UDN with a layer 2 topology to live migrate a pod from `Node 1` to `Node 2`. Each node includes two interfaces:
Revised: To access more configurable options for your network, you can integrate a layer 2 topology with a user-defined network (UDN). The following diagram shows two nodes that use an UDN with a layer 2 topology to live migrate a VM from `Node 1` to `Node 2`. Each node includes two interfaces:
Original: A layer 2 topology creates a virtual switch that is distributed across all nodes in a cluster. Virtual machines and pods connect to this virtual switch so that all these components can communicate with each other within the same subnet. If you decide not to specify a layer 2 subnet, then you must manually configure IP addresses for each pod in your cluster. When you do not specify a layer 2 subnet, port security is limited to preventing Media Access Control (MAC) spoofing only, and does not include IP spoofing. A layer 2 topology creates a single broadcast domain that can be challenging in large network environments, where the topology might cause a broadcast storm that can degrade network performance.
The following diagram shows two nodes that use an UDN with a layer 2 topology to live migrate a pod from `Node 1` to `Node 2`. Each node includes two interfaces:
Revised: To access more configurable options for your network, you can integrate a layer 2 topology with a user-defined network (UDN). The following diagram shows two nodes that use an UDN with a layer 2 topology with pods on each node`. Each node includes two interfaces:
Original: A layer 2 topology creates a virtual switch that is distributed across all nodes in a cluster. Virtual machines and pods connect to this virtual switch so that all these components can communicate with each other within the same subnet. If you decide not to specify a layer 2 subnet, then you must manually configure IP addresses for each pod in your cluster. When you do not specify a layer 2 subnet, port security is limited to preventing Media Access Control (MAC) spoofing only, and does not include IP spoofing. A layer 2 topology creates a single broadcast domain that can be challenging in large network environments, where the topology might cause a broadcast storm that can degrade network performance.
The following diagram shows two nodes that use an UDN with a layer 2 topology to live migrate a pod from `Node 1` to `Node 2`. Each node includes two interfaces:
An external switch connects these two interfaces, while the gateway or router handles routing traffic between the external switch and the layer 2 OVN switch. Pods in a node can use the UDN to communicate with each other. The layer 2 OVN switch handles node traffic over UDN so that live migrate of a pod from one node to another is possible.
Revised: An external switch connects these two interfaces, while the gateway or router handles routing traffic between the external switch and the layer 2 OVN switch. Virtual machines and  pods in a node can use the UDN to communicate with each other. The layer 2 OVN switch handles node traffic over UDN so that live migrate of a VM from one node to another is possible.
Original: A layer 2 topology creates a virtual switch that is distributed across all nodes in a cluster. Virtual machines and pods connect to this virtual switch so that all these components can communicate with each other within the same subnet. If you decide not to specify a layer 2 subnet, then you must manually configure IP addresses for each pod in your cluster. When you do not specify a layer 2 subnet, port security is limited to preventing Media Access Control (MAC) spoofing only, and does not include IP spoofing. A layer 2 topology creates a single broadcast domain that can be challenging in large network environments, where the topology might cause a broadcast storm that can degrade network performance.
The following diagram shows two nodes that use an UDN with a layer 2 topology to live migrate a pod from `Node 1` to `Node 2`. Each node includes two interfaces:
An external switch connects these two interfaces, while the gateway or router handles routing traffic between the external switch and the layer 2 OVN switch. Pods in a node can use the UDN to communicate with each other. The layer 2 OVN switch handles node traffic over UDN so that live migrate of a pod from one node to another is possible.
Revised: An external switch connects these two interfaces, while the gateway or router handles routing traffic between the external switch and the layer 2 OVN switch. VMs and pods in a node can use the UDN to communicate with each other. The layer 2 OVN switch handles node traffic over a UDN so that live migrate of a VM from one node to another is possible.
Original: Activate token quota limits for the {ols-long} Service by defining key-value pairs in the `ConfigMap` resource. The {ols-long} pod mounts the `ConfigMap` resource as a volume, enabling access to the file stored within it. The `OLSConfig` Custom Resource (CR) references the `ConfigMap` resource to obtain the quota limit information.
Revised: Activate token quota limits for the {ols-long} Service by defining key-value pairs in the `ConfigMap` resource. The {ols-long} pod mounts the `ConfigMap` resource as a volume, enabling access to the file stored within it. The `OLSConfig` custom resource (CR) references the `ConfigMap` resource to obtain the quota limit information.
Original: * Requires VMware vSphere 8.0.2 or later or vSphere 7.0 Update 3o or later.

* Only one volume can be migrated at a time.
Revised: * Requires VMware vSphere 8.0.2 or later. Alternatively, requires vSphere 7.0 Update 30 or later.

* You can migrate only one volume at a time.
Original: The default node disruption policy does not contain a policy for changes to the `/etc/containers/registries.conf.d` file. This is because both {product-title} and {op-system-base-full} use the `registries.conf.d` file to specify aliases for image short names. It is recommended that you always pull an image by its fully-qualified name. This is particularly true with public registries, as the image might not deploy if the public registry requires authentication. You can create a user-defined policy to use with the the `/etc/containers/registries.conf.d` file, if needed. However, you should be aware of this recommendation. 
Revised: The default node disruption policy does not contain a policy for changes to the `/etc/containers/registries.conf.d` file. This is because both {product-title} and {op-system-base-full} use the `registries.conf.d` file to specify aliases for image short names. Always pull an image by its fully-qualified name. This is particularly important with public registries, because the image might not deploy if the public registry requires authentication. You can create a user-defined policy to use with the `/etc/containers/registries.conf.d` file, if needed. However, you should be aware of this recommendation.
Original: . Update the `AgentServiceConfig` CR by running the following command:
+
[source,terminal]
----
$ oc edit AgentServiceConfig
----

. Add the following entry to the `spec.osImages` field in the CR:
Revised: . Open the `AgentServiceConfig` CR to update the `spec.osImages` field by running the following command:

[source,terminal]
$ oc edit AgentServiceConfig
Original: |Defines the policy for HTTP traffic compression.
* `httpCompression.mimeTypes` defines a list of or a single MIME type to which compression is applied. For example, `text/css; charset=utf-8`, `text/html`, `text/*`, `image/svg+xml`, `application/octet-stream`, `X-custom/customsub`, using the format pattern, `type/subtype; [;attribute=value]`. The `types` are: application, image, message, multipart, text, video, or a custom type prefaced by `X-`. To see the full notation for MIME types and subtypes, see link:https://datatracker.ietf.org/doc/html/rfc1341#page-7[RFC1341] (IETF Datatracker documentation).
|Describes how HTTP connections are handled if the connection times out before a request is received. Allowed values for this field are `Respond` and `Ignore`. The default value is `Respond`. The following are valid values:
* `Respond`, causes the ingress controller to send an HTTP `400` or `408` response, logs the connection if access logging is enabled, and counts the connection in the appropriate metrics.
* `Ignore`, adds the `http-ignore-probes` parameter in the `HAproxy` configuration. If the field is set to `Ignore`, the ingress controller closes the connection without sending a response, then logs the connection or incrementing metrics.
Usually, empty request connections come from load balancer health probes or web browser preconnects and can be safely ignored. However, network errors and port scans can also create these empty requests, so setting this field to `Ignore` can impede detecting or diagnosing problems and also impede the detection of intrusion attempts.
|Specifies connections for which no request is received and logged. Usually, these empty requests come from load balancer health probes or web browser speculative connections such as preconnects. Logging these types of empty requests can be undesirable. However, network errors and port scans can also create empty requests, so setting this field to `Ignore` can impede detecting or diagnosing problems and also impede the detection of intrusion attempts.
Revised: |`logEmptyRequests` specifies connections for which no request is received and logged. These empty requests come from load balancer health probes or web browser speculative connections (preconnect) and logging these requests can be undesirable. However, these requests can be caused by network errors, in which case logging empty requests can be useful for diagnosing the errors. These requests can be caused by port scans, and logging empty requests can aid in detecting intrusion attempts. Allowed values for this field are `Log` and `Ignore`. The default is `Log`.
Original: * If the router has many connections open because an application running on the cluster does not close connections properly, you can set the `ingress.tuningOptions.serverTimeout` and `spec.tuningOptions.serverFinTimeout` parameters to a lower value, forcing those connections to close sooner.
Revised: *  If you need to configure a TLS security profile for an ingress controller, you can use the `ingress.tlsSecurityProfile` parameter to specify a default or custom individual TLS security profiles. The TLS security profile defines the minimum TLS version and the TLS ciphers for TLS connections for the ingress controllers.
Original: The `ClientCertificatePolicy` subfield accepts one of the two values: `Required` or `Optional`. Note that the ingress controller only checks client certificates for edge-terminated and reencrypt TLS routes; it cannot check certificates for cleartext HTTP or passthrough TLS routes. The `ClientCA` subfield specifies a config map that is in the openshift-ingress namespace. The config map should contain a CA certificate bundle. A config map is required for this field.
Revised: The `ClientCertificatePolicy` subfield accepts one of the two values: `Required` or `Optional`. Note that the ingress controller only checks client certificates for edge-terminated and re-encrypted TLS routes; it cannot check certificates for cleartext HTTP or passthrough TLS routes. The `ClientCA` subfield specifies a config map that is in the openshift-ingress namespace. The config map should contain a CA certificate bundle. A config map is required for this field.
Original: * If the router has many connections open because an application running on the cluster does not close connections properly, you can set the `ingress.tuningOptions.serverTimeout` and `spec.tuningOptions.serverFinTimeout` parameters to a lower value, forcing those connections to close sooner.
Revised: * If you need to configure a TLS security profile for an ingress controller, you can use the `ingress.tlsSecurityProfile` parameter to specify a default or custom individual TLS security profiles. The TLS security profile defines the minimum TLS version and the TLS ciphers for TLS connections for the ingress controllers.
Original: The `AllowedSubjectPatterns` is an optional value that specifies a list of regular expressions, which are matched against the distinguished name on a valid client certificate to filter requests. The regular expressions must use PCRE syntax. This field must contain a valid expression or the MicroShift service will fail. At least one pattern must match a client certificate's distinguished name; otherwise, the Ingress Controller rejects the certificate and denies the connection. If not specified, the Ingress Controller does not reject certificates based on the distinguished name.
Revised: The `AllowedSubjectPatterns` is an optional value that specifies a list of regular expressions, which are matched against the distinguished name on a valid client certificate to filter requests. The regular expressions must use PCRE syntax. This field must contain a valid expression or {microshift-short} fails. At least one pattern must match a client certificate's distinguished name; otherwise, the ingress controller rejects the certificate and denies the connection. If the field value is not set, the ingress controller does not reject certificates based on the distinguished name.
Original: The `ClientCertificatePolicy` subfield accepts one of the two values: `Required` or `Optional`. Note that the ingress controller only checks client certificates for edge-terminated and re-encrypted TLS routes; it cannot check certificates for cleartext HTTP or passthrough TLS routes. The `ClientCA` subfield specifies a config map that is in the openshift-ingress namespace. The config map should contain a CA certificate bundle. A config map is required for this field.
Revised: The `ClientCertificatePolicy` subfield accepts one of the two values: `Required` or `Optional`. The ingress controller only checks client certificates for edge-terminated and re-encrypted TLS routes. The ingress controller cannot check certificates for plain text HTTP or passthrough TLS routes.

The `ClientCA` subfield specifies a config map that is in the `openshift-ingress` namespace. The config map must contain a CA certificate bundle. A config map is required for this field.
Original: |Defines the policy for HTTP traffic compression.
* `httpCompression.mimeTypes` defines a list of or a single MIME type to which compression is applied. For example, `text/css; charset=utf-8`, `text/html`, `text/*`, `image/svg+xml`, `application/octet-stream`, `X-custom/customsub`, using the format pattern, `type/subtype; [;attribute=value]`. The `types` are: application, image, message, multipart, text, video, or a custom type prefaced by `X-`. To see the full notation for MIME types and subtypes, see link:https://datatracker.ietf.org/doc/html/rfc1341#page-7[RFC1341] (IETF Datatracker documentation).
Revised: * `httpCompression.mimeTypes` defines a list of MIME types to which compression should be applied. For example, `text/css; charset=utf-8`, `text/html`, `text/*`, `image/svg+xml`, `application/octet-stream`, `X-custom/customsub`, using the format pattern, `type/subtype; [;attribute=value]`. The `types` are: application, image, message, multipart, text, video, or a custom type prefaced by `X-`. To see the full notation for MIME types and subtypes, see link:https://datatracker.ietf.org/doc/html/rfc1341#page-7[RFC1341] (IETF Datatracker documentation).
Original: |Defines the policy for HTTP traffic compression.
* `httpCompression.mimeTypes` defines a list of or a single MIME type to which compression is applied. For example, `text/css; charset=utf-8`, `text/html`, `text/*`, `image/svg+xml`, `application/octet-stream`, `X-custom/customsub`, using the format pattern, `type/subtype; [;attribute=value]`. The `types` are: application, image, message, multipart, text, video, or a custom type prefaced by `X-`. To see the full notation for MIME types and subtypes, see link:https://datatracker.ietf.org/doc/html/rfc1341#page-7[RFC1341] (IETF Datatracker documentation).
|Describes how HTTP connections are handled if the connection times out before a request is received. Allowed values for this field are `Respond` and `Ignore`. The default value is `Respond`. The following are valid values:
Revised: * `Respond`: If the field is set to `Respond`, the ingress controller sends an HTTP `400` or `408` response, logs the connection if access logging is enabled, and counts the connection in the appropriate metrics.
Original: |Defines the policy for HTTP traffic compression.
* `httpCompression.mimeTypes` defines a list of or a single MIME type to which compression is applied. For example, `text/css; charset=utf-8`, `text/html`, `text/*`, `image/svg+xml`, `application/octet-stream`, `X-custom/customsub`, using the format pattern, `type/subtype; [;attribute=value]`. The `types` are: application, image, message, multipart, text, video, or a custom type prefaced by `X-`. To see the full notation for MIME types and subtypes, see link:https://datatracker.ietf.org/doc/html/rfc1341#page-7[RFC1341] (IETF Datatracker documentation).
|Describes how HTTP connections are handled if the connection times out before a request is received. Allowed values for this field are `Respond` and `Ignore`. The default value is `Respond`. The following are valid values:
* `Respond`, causes the ingress controller to send an HTTP `400` or `408` response, logs the connection if access logging is enabled, and counts the connection in the appropriate metrics.
* `Ignore`, adds the `http-ignore-probes` parameter in the `HAproxy` configuration. If the field is set to `Ignore`, the ingress controller closes the connection without sending a response, then logs the connection or incrementing metrics.
Revised: * `Ignore`: Setting the option to `Ignore` adds the `http-ignore-probes` parameter in the `HAproxy` configuration. If the field is set to `Ignore`, the ingress controller closes the connection without sending a response, then logs the connection or incrementing metrics.