Fix syntax

Author: xenolinux

modules/hcp-bm-access.adoc

@@ -15,14 +15,14 @@ To access the hosted cluster by getting the `kubeconfig` file and credentials di
 
 The secret name formats are as follows:
 
-** `kubeconfig` secret: `<hosted-cluster-namespace>-<name>-admin-kubeconfig` (clusters-hypershift-demo-admin-kubeconfig)
-** `kubeadmin` password secret: `<hosted-cluster-namespace>-<name>-kubeadmin-password` (clusters-hypershift-demo-kubeadmin-password)
+** `kubeconfig` secret: `<hosted_cluster_namespace>-<name>-admin-kubeconfig`. For example, `clusters-hypershift-demo-admin-kubeconfig`.
+** `kubeadmin` password secret: `<hosted_cluster_namespace>-<name>-kubeadmin-password`. For example, `clusters-hypershift-demo-kubeadmin-password`.
 
 The `kubeconfig` secret contains a Base64-encoded `kubeconfig` field, which you can decode and save into a file to use with the following command:
 
 [source,terminal]
 ----
-$ oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
+$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
 ----
 
 The `kubeadmin` password secret is also Base64-encoded. You can decode it and use the password to log in to the API server or console of the hosted cluster.
@@ -35,12 +35,12 @@ The `kubeadmin` password secret is also Base64-encoded. You can decode it and us
 +
 [source,terminal]
 ----
-$ hcp create kubeconfig --namespace <hosted-cluster-namespace> --name <hosted-cluster-name> > <hosted-cluster-name>.kubeconfig
+$ hcp create kubeconfig --namespace <hosted_cluster_namespace> --name <hosted_cluster_name> > <hosted_cluster_name>.kubeconfig
 ----
 
 . After you save the `kubeconfig` file, you can access the hosted cluster by entering the following example command:
 +
 [source,terminal]
 ----
-$ oc --kubeconfig <hosted-cluster-name>.kubeconfig get nodes
+$ oc --kubeconfig <hosted_cluster_name>.kubeconfig get nodes
 ----

modules/hcp-bm-add-np.adoc

@@ -15,30 +15,30 @@ You can create node pools for a hosted cluster by specifying a name, number of r
 +
 [source,terminal]
 ----
-export NODEPOOL_NAME=${CLUSTER_NAME}-extra-cpu
-export WORKER_COUNT="2"
-
 $ hcp create nodepool agent \
-  --cluster-name $CLUSTER_NAME \
-  --name $NODEPOOL_NAME \
-  --node-count $WORKER_COUNT \
-  --agentLabelSelector '{"matchLabels": {"size": "medium"}}' <1>
+  --cluster-name <hosted_cluster_name> \// <1>
+  --name <nodepool_name> \// <2>
+  --node-count <worker_node_count> \// <3>
+  --agentLabelSelector '{"matchLabels": {"size": "medium"}}' <4>
 ----
 +
-<1> The `--agentLabelSelector` is optional. The node pool uses agents with the `"size" : "medium"` label.
+<1> Replace `<hosted_cluster_name>` with your hosted cluster name.
+<2> Replace `<nodepool_name>` with the name of your node pool, for example, `<hosted_cluster_name>-extra-cpu`.
+<3> Replace `<worker_node_count>` with the worker node count, for example, `2`.
+<4> The `--agentLabelSelector` flag is optional. The node pool uses agents with the `"size" : "medium"` label.
 
 . Check the status of the node pool by listing `nodepool` resources in the `clusters` namespace:
 +
 [source,terminal]
 ----
-$oc get nodepools --namespace clusters
+$ oc get nodepools --namespace clusters
 ----
 
 . Extract the `admin-kubeconfig` secret by entering the following command:
 +
 [source,terminal]
 ----
-$ oc extract -n <hosted-control-plane-namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirm
+$ oc extract -n <hosted_control_plane_namespace> secret/admin-kubeconfig --to=./hostedcluster-secrets --confirm
 ----
 +
 .Example output

modules/hcp-bm-autoscale.adoc

@@ -15,7 +15,7 @@ When you need more capacity in your hosted cluster and spare agents are availabl
 +
 [source,terminal]
 ----
-$ oc -n <hosted-cluster-namespace> patch nodepool <hosted-cluster-name> --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
+$ oc -n <hosted_cluster_namespace> patch nodepool <hosted_cluster_name> --type=json -p '[{"op": "remove", "path": "/spec/replicas"},{"op":"add", "path": "/spec/autoScaling", "value": { "max": 5, "min": 2 }}]'
 ----
 +
 [NOTE]
@@ -71,7 +71,7 @@ $ oc apply -f workload-config.yaml
 +
 [source,terminal]
 ----
-$ oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=./hostedcluster-secrets --confirm
+$ oc extract -n <hosted_cluster_namespace> secret/<hosted_cluster_name>-admin-kubeconfig --to=./hostedcluster-secrets --confirm
 ----
 +
 .Example output
@@ -90,7 +90,7 @@ $ oc --kubeconfig ./hostedcluster-secrets get nodes
 +
 [source,terminal]
 ----
-$ oc --kubeconfig ./hostedcluster-secrets -n default delete deployment reversewords
+$ oc --kubeconfig ./hostedcluster-secrets -n <namespace> delete deployment <deployment_name>
 ----
 
 . Wait for several minutes to pass without requiring the additional capacity. On the Agent platform, the agent is decommissioned and can be reused. You can confirm that the node was removed by entering the following command:

modules/hcp-bm-scale-np.adoc

@@ -19,7 +19,7 @@ You can scale up the `NodePool` object by adding nodes to your hosted cluster. W
 +
 [source,terminal]
 ----
-$ oc -n <hosted-cluster-namespace> scale nodepool <nodepool-name> --replicas 2
+$ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 2
 ----
 +
 The Cluster API agent provider randomly picks two agents that are then assigned to the hosted cluster. Those agents go through different states and finally join the hosted cluster as {product-title} nodes. The agents pass through states in the following order:
@@ -35,7 +35,7 @@ The Cluster API agent provider randomly picks two agents that are then assigned
 +
 [source,terminal]
 ----
-$ oc -n <hosted-control-plane-namespace> get agent
+$ oc -n <hosted_control_plane_namespace> get agent
 ----
 +
 .Example output
@@ -51,7 +51,7 @@ da503cf1-a347-44f2-875c-4960ddb04091   hypercluster1   true       auto-assign
 +
 [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}'
+$ 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
@@ -66,14 +66,14 @@ BMH: ocp-worker-1 Agent: da503cf1-a347-44f2-875c-4960ddb04091 State: insufficien
 +
 [source,terminal]
 ----
-$ oc extract -n <hosted-cluster-namespace> secret/<hosted-cluster-name>-admin-kubeconfig --to=- > kubeconfig-<hosted-cluster-name>
+$ oc extract -n <hosted_cluster_namespace> secret/<hosted_cluster_name>-admin-kubeconfig --to=- > kubeconfig-<hosted_cluster_name>
 ----
 
 . After the agents reach the `added-to-existing-cluster` state, verify that you can see the {product-title} nodes in the hosted cluster by entering the following command:
 +
 [source,terminal]
 ----
-$ oc --kubeconfig kubeconfig-<hosted-cluster-name> get nodes
+$ oc --kubeconfig kubeconfig-<hosted_cluster_name> get nodes
 ----
 +
 .Example output
@@ -90,7 +90,7 @@ Cluster Operators start to reconcile by adding workloads to the nodes.
 +
 [source,terminal]
 ----
-$ oc -n <hosted-control-plane-namespace> get machines
+$ oc -n <hosted_control_plane_namespace> get machines
 ----
 +
 .Example output
@@ -107,7 +107,7 @@ The `clusterversion` reconcile process eventually reaches a point where only Ing
 +
 [source,terminal]
 ----
-$ oc --kubeconfig kubeconfig-<hosted-cluster-name> get clusterversion,co
+$ oc --kubeconfig kubeconfig-<hosted_cluster_name> get clusterversion,co
 ----
 +
 .Example output
@@ -116,8 +116,8 @@ $ oc --kubeconfig kubeconfig-<hosted-cluster-name> get clusterversion,co
 NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
 clusterversion.config.openshift.io/version             False       True          40m     Unable to apply 4.x.z: the cluster operator console has not yet successfully rolled out
 
-NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
-clusteroperator.config.openshift.io/console                                    4.12z    False       False         False      11m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused
-clusteroperator.config.openshift.io/csi-snapshot-controller                    4.12z    True        False         False      10m
-clusteroperator.config.openshift.io/dns                                        4.12z    True        False         False      9m16s
+NAME                                                                             VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
+clusteroperator.config.openshift.io/console                                      4.12z     False       False         False      11m     RouteHealthAvailable: failed to GET route (https://console-openshift-console.apps.hypercluster1.domain.com): Get "https://console-openshift-console.apps.hypercluster1.domain.com": dial tcp 10.19.3.29:443: connect: connection refused
+clusteroperator.config.openshift.io/csi-snapshot-controller                      4.12z     True        False         False      10m
+clusteroperator.config.openshift.io/dns                                          4.12z     True        False         False      9m16s
 ----

modules/hcp-ibmz-lpar-agents.adoc

@@ -42,7 +42,7 @@ The `.ins` file includes installation data and is on the FTP server. You can acc
 In {product-title} 4.16, the `.ins` file and `initrd.img.addrsize` are not automatically generated as part of boot-artifacts from the installation program. You must manually generate these files.
 ====
 
-.. Run the following commands to get the size of the `kernel` and `initrd`: 
+.. Run the following commands to get the size of the `kernel` and `initrd`:
 +
 [source,yaml]
 ----
@@ -71,25 +71,25 @@ INITRD_ADDR_SIZE_OFFSET=0x00010408
 OFFSET_HEX=$(printf '0x%08x\n' $offset)
 ----
 
-.. Convert the address and size to binary format by running the following commands:
+.. Convert the address and size to binary format by running the following command:
 +
 [source,terminal]
 ----
-printf "$(printf '%016x\n' $initrd_size)" | xxd -r -p > temp_size.bin
+$ printf "$(printf '%016x\n' $initrd_size)" | xxd -r -p > temp_size.bin
 ----
 
 .. Merge the address and size binaries by running the following command:
 +
 [source,terminal]
 ----
-cat temp_address.bin temp_size.bin > "$INITRD_IMG_NAME.addrsize"
+$ cat temp_address.bin temp_size.bin > "$INITRD_IMG_NAME.addrsize"
 ----
 
 .. Clean up temporary files by running the following command:
 +
 [source,terminal]
 ----
-rm -rf temp_address.bin temp_size.bin
+$ rm -rf temp_address.bin temp_size.bin
 ----
 
 .. Create the `.ins` file. The file is based on the paths of the `kernel.img`, `initrd.img`, `initrd.img.addrsize`, and `cmdline` files and the memory locations where the data is to be copied.
@@ -102,8 +102,8 @@ $INITRD_IMG_NAME.addrsize $INITRD_ADDR_SIZE_OFFSET
 $CMDLINE_PATH $KERNEL_CMDLINE_OFFSET
 ----
 
-. Transfer the `initrd`, `kernel`, `generic.ins`, and `initrd.img.addrsize` parameter files to the file server. For more information about how to transfer the files with FTP and boot, see _Installing in an LPAR_.    
+. Transfer the `initrd`, `kernel`, `generic.ins`, and `initrd.img.addrsize` parameter files to the file server. For more information about how to transfer the files with FTP and boot, see _Installing in an LPAR_.
 
 . Start the machine.
 
-. Repeat the procedure for all other machines in the cluster.
+. Repeat the procedure for all other machines in the cluster.