[OSDOCS#20050]: Implemented review comments from Seb for OSDOCS-18856

modules/installation-manual-recovering-when-auto-recovery-is-unavail.adoc

@@ -146,7 +146,7 @@ $ sudo pcs stonith config <node_name>_redfish
 +
 If fencing is required but is not functioning, ensure that the Redfish fencing endpoint is accessible and verify that the credentials are correct.
 +
-If you have verified the failed node is permanently inaccessible but automated fencing cannot function, verify the failed node meets ALL of the following conditions:
+If you have verified the failed node is permanently inaccessible but automated fencing cannot function, verify the failed node meets all of the following conditions:
 
 * The node is powered off and cannot be restarted.
 * The node cannot access any shared storage or cluster resources.
@@ -181,7 +181,7 @@ If the recovery is successful, no further action is required. If the issue persi
 
 . Recover from dual node power loss where both nodes are recoverable:
 +
-This procedure applies when both control plane nodes lost power and both nodes can be restarted. If only one node can be restarted, proceed to step 4.
+This procedure applies when both control plane nodes lost power and both nodes can be restarted. If only one node can be restarted, proceed to the next step.
 
 .. Power on both control plane nodes.
 +
@@ -332,13 +332,13 @@ Error: Unable to get quorum status:
 
 .. Verify that the failed node is permanently inaccessible before proceeding.
 +
-Before confirming to Pacemaker that the failed node is fenced, you must ensure that the failed node meets ALL of the following conditions:
+Before confirming to Pacemaker that the failed node is fenced, you must ensure that the failed node meets all of the following conditions:
 
  - The node is powered off and cannot be restarted
  - The node cannot access any shared storage or cluster resources
  - The node is completely isolated from the cluster network
 +
-If the failed node is accessible or can access shared resources, DO NOT proceed with this step. Confirming fencing for a node that is still active can cause data corruption and cluster failure.
+If the failed node is accessible or can access shared resources, do not proceed with this step. Confirming fencing for a node that is still active can cause data corruption and cluster failure.
 
 .. Confirm to Pacemaker that the failed node is fenced by running the following command:
 +
@@ -355,7 +355,7 @@ WARNING: If node 'master-1' is not powered off or it does have access to shared
 Type 'yes' or 'y' to proceed, anything else to cancel:
 ----
 +
-Replace <failed_node_name> with the name of the failed control plane node (for example, control-plane-1).
+Replace `<failed_node_name>` with the name of the failed control plane node (for example, control-plane-1).
 
 .. Verify that quorum is restored by running the following command:
 +
@@ -395,30 +395,31 @@ Flags:            2Node Quorate
 ----
 $ sudo pcs resource status etcd
 ----
-+
-If etcd is not running, restart it by running the following command:
+
+.. If etcd is not running, restart it by running the following command:
 +
 [source,terminal]
 ----
 $ sudo pcs resource cleanup etcd
 ----
-+
-Wait up to 5 minutes for etcd to start. Check the status periodically by running the following command:
+
+.. Wait up to 5 minutes for etcd to start. Check the status periodically by running the following command:
 +
 [source,terminal]
 ----
 $ sudo pcs resource status etcd
 ----
 +
 The command shows that the `podman-etcd` resource is started.
-If the container is started successfully, you can see the logs by running the following command:
+
+.. If the container is started successfully, view the logs by running the following command:
 +
 [source,terminal]
 ----
 $ sudo podman logs etcd
 ----
-+
-If the container is not started, you can see the logs by running the following command:
+
+.. If the container is not started, view the logs by running the following command:
 +
 [source,terminal]
 ----