Merge pull request #141 from bpradipt/doc-4.5

Minor changes to HA bastion description

docs/var.tfvars-doc.md

@@ -69,11 +69,13 @@ worker      = {memory      = "32",   processors  = "0.5",  "count"   = 2}
 
 `memory` is in `GBs` and `count` specifies the number of VMs that should be created for each type.
 
-To enable high availability (HA) for cluster services running on the bastion set the `bastion.count` value to 2. Note that in case of HA, the automation will not setup additional storage (eg: NFS). Value 1 for `bastion.count` implies the default non-HA bastion setup.
+To enable high availability (HA) for the bastion node set the bastion `count` value to `2`.
+Note that when HA is enabled, the automation will not setup NFS storage on bastion. Value `1` for bastion `count` implies the default non-HA bastion setup.
 
-You can optionally set worker.count value to 0 in which case all the clusters pods will be running on the master/supervisor nodes. Ensure you use proper sizing for master/supervisor nodes to avoid resource starvation for containers.
+You can optionally set worker `count` value to `0` in which case all the cluster pods will be running on the master/supervisor nodes.
+Ensure that you use proper sizing for master/supervisor nodes to avoid resource starvation for containers.
 
-For PowerVS processors are equal to entitled physical count. So **N** processors == **N** physical core entitlements == **ceil[N]** vCPUs.
+For PowerVS, processors are equal to entitled physical count. So **N** processors == **N** physical core entitlements == **ceil[N]** vCPUs.
 Here are some examples to help you understand the relationship.
 
 - Example 1