Add headings

Author: DaveCTurner

docs/reference/modules/discovery/adding-removing-nodes.asciidoc

@@ -3,18 +3,23 @@
 
 As nodes are added or removed Elasticsearch maintains an optimal level of fault
 tolerance by automatically updating the cluster's _voting configuration_, which
-is the set of <<master-node,master-eligible nodes>> whose responses are counted when making
-decisions such as electing a new master or committing a new cluster state.
+is the set of <<master-node,master-eligible nodes>> whose responses are counted
+when making decisions such as electing a new master or committing a new cluster
+state.
 
 It is recommended to have a small and fixed number of master-eligible nodes in a
 cluster, and to scale the cluster up and down by adding and removing
 master-ineligible nodes only. However there are situations in which it may be
 desirable to add or remove some master-eligible nodes to or from a cluster.
 
+==== Adding master-eligible nodes
+
 If you wish to add some master-eligible nodes to your cluster, simply configure
 the new nodes to find the existing cluster and start them up. Elasticsearch will
 add the new nodes to the voting configuration if it is appropriate to do so.
 
+==== Removing master-eligible nodes
+
 When removing master-eligible nodes, it is important not to remove too many all
 at the same time. For instance, if there are currently seven master-eligible
 nodes and you wish to reduce this to three, it is not possible simply to stop
@@ -24,23 +29,22 @@ cannot take any further actions.
 
 As long as there are at least three master-eligible nodes in the cluster, as a
 general rule it is best to remove nodes one-at-a-time, allowing enough time for
-the cluster to <<modules-discovery-quorums,auto-adjust>> the voting
+the cluster to <<modules-discovery-quorums,automatically adjust>> the voting
 configuration and adapt the fault tolerance level to the new set of nodes.
 
 If there are only two master-eligible nodes remaining then neither node can be
-safely removed since both are required to reliably make progress. You must
-first inform Elasticsearch that one of the nodes should not be part of the
-voting configuration, and that the voting power should instead be given to
-other nodes. You can then take the excluded node offline without preventing
-the other node from making progress. A node which is added to a voting
-configuration exclusion list still works normally, but Elasticsearch
-tries to remove it from the voting configuration so its vote is no longer required.
-Importantly, Elasticsearch will never automatically move a node on the voting
-exclusions list back into the voting configuration. Once an excluded node has
-been successfully auto-reconfigured out of the voting configuration, it is safe
-to shut it down without affecting the cluster's master-level availability. A
-node can be added to the voting configuration exclusion list using the
-following API:
+safely removed since both are required to reliably make progress. You must first
+inform Elasticsearch that one of the nodes should not be part of the voting
+configuration, and that the voting power should instead be given to other nodes.
+You can then take the excluded node offline without preventing the other node
+from making progress. A node which is added to a voting configuration exclusion
+list still works normally, but Elasticsearch tries to remove it from the voting
+configuration so its vote is no longer required.  Importantly, Elasticsearch
+will never automatically move a node on the voting exclusions list back into the
+voting configuration. Once an excluded node has been successfully
+auto-reconfigured out of the voting configuration, it is safe to shut it down
+without affecting the cluster's master-level availability. A node can be added
+to the voting configuration exclusion list using the following API:
 
 [source,js]
 --------------------------------------------------
@@ -58,14 +62,14 @@ POST /_cluster/voting_config_exclusions/node_name?timeout=1m
 
 The node that should be added to the exclusions list is specified using
 <<cluster-nodes,node filters>> in place of `node_name` here. If a call to the
-voting configuration exclusions API fails, you can safely retry it.
-Only a successful response guarantees that the node has actually been removed
-from the voting configuration and will not be reinstated.
+voting configuration exclusions API fails, you can safely retry it.  Only a
+successful response guarantees that the node has actually been removed from the
+voting configuration and will not be reinstated.
 
 Although the voting configuration exclusions API is most useful for down-scaling
 a two-node to a one-node cluster, it is also possible to use it to remove
-multiple master-eligible nodes all at the same time. Adding multiple nodes
-to the exclusions list has the system try to auto-reconfigure all of these nodes
+multiple master-eligible nodes all at the same time. Adding multiple nodes to
+the exclusions list has the system try to auto-reconfigure all of these nodes
 out of the voting configuration, allowing them to be safely shut down while
 keeping the cluster available. In the example described above, shrinking a
 seven-master-node cluster down to only have three master nodes, you could add
@@ -103,9 +107,9 @@ maintenance is complete. Clusters should have no voting configuration exclusions
 in normal operation.
 
 If a node is excluded from the voting configuration because it is to be shut
-down permanently, its exclusion can be removed after it is shut down and
-removed from the cluster. Exclusions can also be cleared if they were
-created in error or were only required temporarily:
+down permanently, its exclusion can be removed after it is shut down and removed
+from the cluster. Exclusions can also be cleared if they were created in error
+or were only required temporarily:
 
 [source,js]
 --------------------------------------------------