resolve comments

Author: syzehra

articles/operator-nexus/howto-cluster-runtime-upgrade.md

@@ -146,11 +146,11 @@ During a runtime upgrade the cluster will enter a state of `Upgrading`  In the e
 
 ### Impact on Nexus Kubernetes tenant workloads during cluster runtime upgrade
 
-During a Nexus cluster runtime upgrade, the Nexus Kubernetes workload cluster nodes are cordoned and drained to ensure the proper draining of CNF Pods while upgrading the Bare Metal Hosts (BMH) where the cluster Virtual Machines (VMs) are hosted. Cordoning the tenant cluster node and draining the Pods from it before the BMH upgrade allows the Pods to migrate to other nodes within the tenant cluster if sufficient capacity exists. If there is no capacity, the Pods will enter a Pending state after the drain process.
+During a runtime upgrade, impacted Nexus Kubernetes cluster nodes are cordoned and drained before the Bare Metal Hosts (BMH) are upgraded.  Cordoning of the cluster node prevents new pods from being scheduled onto it and draining of the cluster node allows pods that are running tenant workload opportunity to move to another available cluster node in order to help minimize service impact.  Draining mechanism is affected by available capacity on the Nexus Kubernetes cluster, if the cluster is near capacity and there is no where for the pods to move, they will enter into Pending state after the drain process.
 
-Once the cordon and drain process of the tenant cluster VMs on the BMH is complete, the BMH upgrade proceeds. The drain timeout for the tenant cluster node is set to 10 minutes. If the draining process exceeds this duration, the BMH upgrade will still continue after the timeout, and the Bare Metal Host will be rebooted. This process occurs in parallel, so the maximum overall wait time for the entire rack is limited to 10 minutes. After completing the BMH upgrade and rejoining the bare metal cluster, and once the VM is up and joins the cluster, the VM will be uncordoned.
+Once the cordon and drain process of the tenant cluster node is completed, the BMH upgrade proceeds. Each tenant cluster node is allowed up to 10 minutes for the draining process to complete, after which the BMH upgrade will proceed regardless, this ensure BMH upgrade will continue to proceed without long delay.  The BMHs are upgraded in parallel within the same rack, the benefit of this is that the maximum overall wait time for a rack upgrade is also kept at 10 minutes regardless of how many nodes are available.  After the completion of each BMH upgrade, the Nexus kubernetes cluster node will start and rejoin the cluster, it will then be uncordoned so pods can be scheduled on the node again.
 
-It's important to note that the tenant cluster VMs won't shut down after the cordon and drain process. The BMH is rebooted as soon as the workload cluster node drain is done, or if the drain isn't successful within 10 minutes. Additionally, the cordon and drain is not initiated by power-off or restart actions on the Bare Metal Host; it's exclusively activated for Nexus runtime upgrades.
+It's important to note that the Nexus Kubernetes cluster node won't be shut down after the cordon and drain process. The BMH is rebooted with the new image as soon as all the Nexus Kubernetes cluster nodes are cordoned and drained, after 10 minutes if the drain process isn't completed. Additionally, the cordon and drain is not initiated for power-off or restart actions of the BMH; it's exclusively activated only during a runtime upgrade.
 
 <!-- LINKS - External -->
 [installation-instruction]: https://aka.ms/azcli