gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: This creates two `infraenv` resources with `x86_64` and `ppc64le` architectures. Before proceeding, make sure that the OS images for both architectures are added to the `AgentServiceConfig` resource. After this you can use the above infraenvs to get the minimal iso and follow the `create-agent-cluster.md` to add them to your cluster as agents.
Revised: 
This creates two `infraenv` resources with `x86_64` and `ppc64le` architectures.

. Verify that the OS images for both architectures are added to the `AgentServiceConfig` resource.
. Use the above infraenvs to get the minimal ISO image.
. Follow the steps in the `create-agent-cluster.md` to add them to your cluster as agents.
Original: You can create heterogeneous node pools on the agent platform. It enables clusters to run diverse machine types e.g. `x86_64` or `ppc64le` within a single hosted cluster. The following example show how to configure a heterogeneous node pool.
Revised: You can create heterogeneous node pools on the agent platform. It enables clusters to run diverse machine types, for example, `x86_64` or `ppc64le`, within a single hosted cluster. The following example shows how to configure a heterogeneous node pool.
Original: You can create heterogeneous node pools on the agent platform. It enables clusters to run diverse machine types e.g. `x86_64` or `ppc64le` within a single hosted cluster. The following example show how to configure a heterogeneous node pool.
Revised: You can create heterogeneous node pools on the agent platform. It enables clusters to run diverse machine types e.g. `x86_64` or `ppc64le` within a single hosted cluster.

To create a heterogeneous node pool, you must create an agent service configuration custom resource (CR) that informs the Operator how much storage is needed for components such as the database and filesystem. The CR also defines which {product-title} versions to maintain.
Original: <1> The Multicluster Engine (MCE) `agentserviceconfig` config, database volume name.
<2> The Multicluster Engine (MCE) `agentserviceconfig` config, filesystem volume name.
Revised: <1> The {mce} `agentserviceconfig` config, database volume name.
<2> The {mce-short} `agentserviceconfig` config, filesystem volume name.
Original: <1> The Multicluster Engine (MCE) `agentserviceconfig` config, database volume name.
<2> The Multicluster Engine (MCE) `agentserviceconfig` config, filesystem volume name.
<3> The current version of {product-title}.
<4> The current {product-title} release version for x86.
<5> The ISO URL for x86.
<6> The root fs URL for X8.
<7> The CPU architecture for x86.
<8> The current Openshift version.
<9> The Openshift release version for `ppc64le`.
<10> The ISO URL for `ppc64le`. 
<11> The root fs URL for `ppc64le`.
<12> The CPU architecture for `ppc64le`.
Revised: <1> Specify the {mce} `agentserviceconfig` config, database volume name.
<2> Specify the {mce-short} `agentserviceconfig` config, filesystem volume name.
<3> Specify the current version of {product-title}.
<4> Specify the current {product-title} release version for x86.
<5> Specify the ISO URL for x86.
<6> Specify the root fs URL for X8.
<7> Specify the CPU architecture for x86.
<8> Specify the current Openshift version.
<9> Specify the Openshift release version for `ppc64le`.
<10> Specify the ISO URL for `ppc64le`.
<11> Specify the root fs URL for `ppc64le`.
<12> Specify the CPU architecture for `ppc64le`.
Original: .Procedure

. Create a hosted cluster for heterogeneous node pool
+
Use a multi-architecture release image when creating the cluster to enable support for heterogeneous node pools. Find the latest multi architecture images on the link:https://multi.ocp.releases.ci.openshift.org/[Multi-arch release images] page.
Revised: .Prerequisites

* You used a multi-architecture release image to enable support for heterogeneous node pools when creating a hosted cluster. Find the latest multi architecture images on the link:https://multi.ocp.releases.ci.openshift.org/[Multi-arch release images] page.

.Procedure
Original: $ hypershift create cluster agent \
    --name=<hosted_cluster_name> \ <1>
    --pull-secret=<pull_secret_file> \ <2>
    --agent-namespace=<hosted_control_plane_namespace> \ <3>
    --base-domain=<basedomain> \ <4>
    --api-server-address=api.<hosted_cluster_name>.<basedomain> \
    --release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release> <5>
----
Revised: $ hypershift create cluster agent \
Original: <1> The hosted cluster name.
<2> The pull secret file path.
<3> The namespace for the hosted control plane.
<4> The basedomain for the hosted cluster.
<5> The current Openshift release version.
Revised: <1> Specify the hosted cluster name.
<2> Specify the pull secret file path.
<3> Specify the namespace for the hosted control plane.
<4> Specify the base domain for the hosted cluster.
<5> Specify the current {product-title} release version.
Original:           inventory.agent-install.openshift.io/cpu-architecture: <arch_ppc64le>
    type: Agent
  release:
    image: quay.io/openshift-release-dev/ocp-release:<ocp_release>
  replicas: 0
----
+
. To create a node pool of architecture `ppc64le` with zero replicas, see the following configuration:
Revised: inventory.agent-install.openshift.io/cpu-architecture: <arch_ppc64le> <1>
type: Agent
release:
image: quay.io/openshift-release-dev/ocp-release:<ocp_release>
replicas: 0
<1> This selector block is selects the agents that match the specified label.
To create a node pool of architecture `ppc64le` with zero replicas, specify `ppc64le`.
This ensures that it selects only agents from `ppc64le` architecture when it scales.
Original: Domain Name Service (DNS) configuration for hosted control planes is done basically for external clients to reach ingress controllers so that it can route traffic to internal components. Configuring this setting ensures that traffic is routed to either worker node e.g. `ppc64le` or `x86_64` node.
Revised: Domain Name Service (DNS) configuration for hosted control planes enables external clients to reach ingress controllers so that they can route traffic to internal components. Configuring this setting ensures that traffic is routed to either `ppc64le` or `x86_64` compute node.
Original: You can point an `*.apps.<cluster_name>` record to either one of the worker nodes where ingress application is hosted. Or, if you are able to set up a load balancer on top of the worker nodes, point this record to this load balancer. When you are creating a heterogeneous node pool, make sure the workers are reachable from each other or keep them in the same network.
Revised: You can point an `*.apps.<cluster_name>` record to either of the compute nodes where the ingress application is hosted. Or, if you are able to set up a load balancer on top of the compute nodes, point this record to this load balancer. When you are creating a heterogeneous node pool, make sure the compute nodes can reach each other or keep them in the same network.
Original: For heterogeneous node pools, you must create the `infraenv` custom resource (CR) for each architecture. For example, for node pools with `x86_64` and `ppc64le` architectures, create the `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: +
[source,yaml]
----
envsubst <<"EOF" | oc apply -f -
apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: <hosted_cluster_name>-<arch_ppc64le> <5>
  namespace: <hosted_control_plane_namespace>
spec:
  cpuArchitecture: <arch_ppc64le>
  pullSecretRef:
    name: pull-secret
  sshAuthorizedKey: <ssh_pub_key>
EOF
----
Revised: . Do step 2, whatever that is, by running the following command:
[source,terminal]
$ envsubst <<"EOF" | oc apply -f -
Original: . The following commands can be used to verify if the `infraenv` resources are created successfully:
+
[source,terminal]
----
$ oc describe InfraEnv <hosted_cluster_name>-<arch_x86>
----
+
[source,terminal]
----
$ oc describe InfraEnv <hosted_cluster_name>-<arch_ppc64le>
----

. These commands generate a live ISO that allows machines either a virtual machines or a bare-metal to join as agents.
+
. Live ISO for `x86_64`:
+
[source,terminal]
----
$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_x86> -ojsonpath="{.status.isoDownloadURL}"
----
+
Revised: . To verify that the `infraenv` resources are created successfully run the following commands:

** Verify that the x86 `infraenv` resource is created successfully:
[source,terminal]
$ oc describe InfraEnv <hosted_cluster_name>-<arch_x86>

** Verify that the `ppc64le` `infraenv` resource is created successfully:
[source,terminal]
$ oc describe InfraEnv <hosted_cluster_name>-<arch_ppc64le>
Original: . These commands generate a live ISO that allows machines either a virtual machines or a bare-metal to join as agents.
+
. Live ISO for `x86_64`:
+
[source,terminal]
----
$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_x86> -ojsonpath="{.status.isoDownloadURL}"
----
+
. Live ISO for `ppc64le`:
+
[source,terminal]
----
$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_ppc64le> -ojsonpath="{.status.isoDownloadURL}"
----
Revised: . Generate a live ISO that allows machines either a virtual machine or a bare-metal machine to join as agents by running the following commands:

. Generate a live ISO for `x86_64`:

[source,terminal]
$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_x86> -ojsonpath="{.status.isoDownloadURL}"

. Generate a live ISO for `ppc64le`:

[source,terminal]
$ oc -n <hosted_control_plane_namespace> get InfraEnv <hosted_cluster_name>-<arch_ppc64le> -ojsonpath="{.status.isoDownloadURL}"
Original: After your agents are approved, you can scale the node pools, `agentLabelSelector` configured in the node pool ensures that only matching agents added to the cluster. This also aids in descaling the node pool. To remove specific architecture nodes from the cluster, descale the corresponding node pool.
Revised: After your agents are approved, you can scale the node pools. The `agentLabelSelector` value that is configured in the node pool ensures that only matching agents are added to the cluster. This also helps scale down the node pool. To remove specific architecture nodes from the cluster, scale down the corresponding node pool.
Original: 
[Note]
====
The `ClusterAPI` agent provider will pick two agents randomly that will get assigned to the hosted cluster. These agents will go over different states and will finally join the hosted cluster as the OpenShift nodes. The various agent states are `binding`, `discovering`, `insufficient`, `installing`, `installing-in-progress` and `added-to-existing-cluster`.
====
Revised: 
[NOTE]
====
The Cluster API agent provider picks two agents randomly to assign to the hosted cluster. These agents pass through different states and then join the hosted cluster as {product-title} nodes. The various agent states are `binding`, `discovering`, `insufficient`, `installing`, `installing-in-progress`, and `added-to-existing-cluster`.
====
Original: +
[source,yaml]
----
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent
NAME                                   CLUSTER         APPROVED   ROLE          STAGE
4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign  
d9198891-39f4-4930-a679-65fb142b108b                   true       auto-assign  
da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign
----
+
[source,yaml]
----
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
----
+ 
. Once the agents reach the `added-to-existing-cluster` state, check the OpenShift nodes after a few moments:
+
[source,yaml]
----
oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
NAME           STATUS   ROLES    AGE     VERSION
ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
ocp-worker-2   Ready    worker   6m3s    v1.24.0+3882f8f
----
+
. Adding workloads to the nodes can reconcile some cluster operators. The following command displays that two machines are created after scaling up the node pool:
Revised: 
[source,terminal]
$ oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent

.Example output
NAME                                   CLUSTER         APPROVED   ROLE          STAGE
4dac1ab2-7dd5-4894-a220-6a3473b67ee6   hypercluster1   true       auto-assign
d9198891-39f4-4930-a679-65fb142b108b                   true       auto-assign
da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign

.Some new command intro here:

[source,terminal]
$ oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get agent -o jsonpath='{range .items[*]}BMH: {@.metadata.labels.agent-install\.openshift\.io/bmh} Agent: {@.metadata.name} State: {@.status.debugInfo.state}{"\n"}{end}'

.Example output
BMH: ocp-worker-2 Agent: 4dac1ab2-7dd5-4894-a220-6a3473b67ee6 State: binding
BMH: ocp-worker-0 Agent: d9198891-39f4-4930-a679-65fb142b108b State: known-unbound
BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficient
Original: [source,yaml]
----
oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes
NAME           STATUS   ROLES    AGE     VERSION
ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
ocp-worker-2   Ready    worker   6m3s    v1.24.0+3882f8f
----
+
. Adding workloads to the nodes can reconcile some cluster operators. The following command displays that two machines are created after scaling up the node pool:
+
[source,yaml]
----
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get machines
NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.11.5
hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.11.5
----
+
. Access the hostcluster by using the `kubeconfig`:
+
[source,yaml]
----
hypershift create kubeconfig –namespace <hosted_control_plane_namespace> –name example >> example.kubeconfig
Revised: [source,terminal]
$ oc --kubeconfig ${HOSTED_CLUSTER_NAME}.kubeconfig get nodes

.Example output
NAME           STATUS   ROLES    AGE     VERSION
ocp-worker-1   Ready    worker   5m41s   v1.24.0+3882f8f
ocp-worker-2   Ready    worker   6m3s    v1.24.0+3882f8f
Original: . Adding workloads to the nodes can reconcile some cluster operators. The following command displays that two machines are created after scaling up the node pool:
+
[source,yaml]
----
oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get machines
NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.11.5
hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.11.5
----
+
. Access the hostcluster by using the `kubeconfig`:
+
[source,yaml]
----
hypershift create kubeconfig –namespace <hosted_control_plane_namespace> –name example >> example.kubeconfig
----
Revised: . Adding workloads to the nodes might reconcile some cluster Operators. The following command displays that two machines are created after scaling up the node pool:

[source,terminal]
$ oc -n ${HOSTED_CONTROL_PLANE_NAMESPACE} get machines

.Example output
NAME                            CLUSTER               NODENAME       PROVIDERID                                     PHASE     AGE   VERSION
hypercluster1-c96b6f675-m5vch   hypercluster1-b2qhl   ocp-worker-1   agent://da503cf1-a347-44f2-875c-4960ddb04091   Running   15m   4.11.5
hypercluster1-c96b6f675-tl42p   hypercluster1-b2qhl   ocp-worker-2   agent://4dac1ab2-7dd5-4894-a220-6a3473b67ee6   Running   15m   4.11.5
Original: . Access the hostcluster by using the `kubeconfig`:
+
[source,yaml]
----
hypershift create kubeconfig –namespace <hosted_control_plane_namespace> –name example >> example.kubeconfig
----
Revised: . To access the host cluster by using the `kubeconfig`, run the following command:

[source,terminal]
$ hypershift create kubeconfig –namespace <hosted_control_plane_namespace> –name example >> example.kubeconfig
Original: You can add Agents by manually configuring the machine to boot with the live ISO. The live ISO may be downloaded and used to boot a node a bare-metal or a virtual machine. On boot, the node will communicate with the `assisted-service` and register as an Agent in the same namespace as the `infraenv`. Once each agent is created, optionally set its `installation_disk_id` and `hostname` in the specifications. Then approve it to indicate that the agent is ready for use.
Revised: You can 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 register as an agent in the same namespace as the `infraenv`. Once 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: . The following command can be used to get agents:
+
[source,yaml]
----
oc -n <hosted_control_plane_namespace> get agents
NAME                                   CLUSTER   APPROVED   ROLE          STAGE
86f7ac75-4fc4-4b36-8130-40fa12602218                        auto-assign
e57a637f-745b-496e-971d-1abbf03341ba                        auto-assign
----
+
. The following command can be used to patch the agent:
+
[source,yaml]
----
oc -n <hosted_control_plane_namespace> patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' --type merge
----
+
. The following command can be used to patch the agent:
+
[source,yaml]
----
oc -n <hosted_control_plane_namespace> patch agent 23d0c614-2caa-43f5-b7d3-0b3564688baa -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-1.example.krnl.es"}}' --type merge
----
+
. The following command can be used to check the agent approval status:
+
[source,yaml]
----
oc -n <hosted_control_plane_namespace> get agents
NAME                                   CLUSTER   APPROVED   ROLE          STAGE
86f7ac75-4fc4-4b36-8130-40fa12602218             true       auto-assign
e57a637f-745b-496e-971d-1abbf03341ba             true       auto-assign
----
Revised: . List the agents by running the following command:

[source,terminal]
$ oc -n <hosted_control_plane_namespace> get agents

.Example output
NAME                                   CLUSTER   APPROVED   ROLE          STAGE
86f7ac75-4fc4-4b36-8130-40fa12602218                        auto-assign
e57a637f-745b-496e-971d-1abbf03341ba                        auto-assign

. Patch an agent by running the following command:

[source,terminal]
$ oc -n <hosted_control_plane_namespace> patch agent 86f7ac75-4fc4-4b36-8130-40fa12602218 -p '{"spec":{"installation_disk_id":"/dev/sda","approved":true,"hostname":"worker-0.example.krnl.es"}}' --type merge

. Check the agent approval status by running the following command:

[source,terminal]
$ oc -n <hosted_control_plane_namespace> get agents

.Example output
NAME                                   CLUSTER   APPROVED   ROLE          STAGE
86f7ac75-4fc4-4b36-8130-40fa12602218             true       auto-assign
e57a637f-745b-496e-971d-1abbf03341ba             true       auto-assign
Original: To create a heterogeneous node pool, you must create an agent service configuration custom resource (CR) that informs the Operator how much storage is needed for components such as the database and filesystem. The CR also defines which {product-title} versions to maintain.
Revised: To create a heterogeneous node pool, you must create an `AgentServiceConfig` custom resource (CR) that informs the Operator how much storage is needed for components such as the database and filesystem. The CR also defines which {product-title} versions to maintain.
Original: * You used a multi-architecture release image to enable support for heterogeneous node pools when creating a hosted cluster. Find the latest multi architecture images on the link:https://multi.ocp.releases.ci.openshift.org/[Multi-arch release images] page.
Revised: * You used a multi-architecture release image to enable support for heterogeneous node pools when creating a hosted cluster. Find the latest multi-architecture images on the link:https://multi.ocp.releases.ci.openshift.org/[Multi-arch release images] page.
Original: You can 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 register as an agent in the same namespace as the `infraenv`. Once 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 register as an agent in the same namespace as the `infraenv`. Once 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: You can 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 register as an agent in the same namespace as the `infraenv`. Once 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 can 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.