more fixes to pages

Author: georgewallace

deploy-manage/distributed-architecture/discovery-cluster-formation/discovery-hosts-providers.md

@@ -25,7 +25,6 @@ By default the cluster formation module offers two seed hosts providers to confi
 
 Each seed hosts provider yields the IP addresses or hostnames of the seed nodes. If it returns any hostnames then these are resolved to IP addresses using a DNS lookup. If a hostname resolves to multiple IP addresses then {{es}} tries to find a seed node at all of these addresses. If the hosts provider does not explicitly give the TCP port of the node by then, it will implicitly use the first port in the port range given by `transport.profiles.default.port`, or by `transport.port` if `transport.profiles.default.port` is not set. The number of concurrent lookups is controlled by `discovery.seed_resolver.max_concurrent_resolvers` which defaults to `10`, and the timeout for each lookup is controlled by `discovery.seed_resolver.timeout` which defaults to `5s`. Note that DNS lookups are subject to [JVM DNS caching](../../deploy/self-managed/networkaddress-cache-ttl.md).
 
-
 #### Settings-based seed hosts provider [settings-based-hosts-provider] 
 
 The settings-based seed hosts provider uses a node setting to configure a static list of the addresses of the seed nodes. These addresses can be given as hostnames or IP addresses; hosts specified as hostnames are resolved to IP addresses during each round of discovery.
@@ -42,8 +41,6 @@ discovery.seed_hosts:
 1. The port will default to `transport.profiles.default.port` and fallback to `transport.port` if not specified.
 2. If a hostname resolves to multiple IP addresses, {{es}} will attempt to connect to every resolved address.
 
-
-
 #### File-based seed hosts provider [file-based-hosts-provider] 
 
 The file-based seed hosts provider configures a list of hosts via an external file.  {{es}} reloads this file when it changes, so that the list of seed nodes can change dynamically without needing to restart each node. For example, this gives a convenient mechanism for an {{es}} instance that is run in a Docker container to be dynamically supplied with a list of IP addresses to connect to when those IP addresses may not be known at node startup.
@@ -74,19 +71,14 @@ Host names are allowed instead of IP addresses and are resolved by DNS as descri
 
 You can also add comments to this file. All comments must appear on their lines starting with `#` (i.e. comments cannot start in the middle of a line).
 
-
-#### EC2 hosts provider [ec2-hosts-provider] 
+#### EC2 hosts provider [ec2-hosts-provider]
 
 The [EC2 discovery plugin](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch-plugins/discovery-ec2.md) adds a hosts provider that uses the [AWS API](https://github.com/aws/aws-sdk-java) to find a list of seed nodes.
 
-
-#### Azure Classic hosts provider [azure-classic-hosts-provider] 
+#### Azure Classic hosts provider [azure-classic-hosts-provider]
 
 The [Azure Classic discovery plugin](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch-plugins/discovery-azure-classic.md) adds a hosts provider that uses the Azure Classic API find a list of seed nodes.
 
-
 #### Google Compute Engine hosts provider [gce-hosts-provider] 
 
 The [GCE discovery plugin](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch-plugins/discovery-gce.md) adds a hosts provider that uses the GCE API find a list of seed nodes.
-
-

deploy-manage/distributed-architecture/discovery-cluster-formation/modules-discovery-bootstrap-cluster.md

@@ -25,7 +25,6 @@ If you leave `cluster.initial_master_nodes` in place once the cluster has formed
 
 ::::
 
-
 The simplest way to create a new cluster is for you to select one of your master-eligible nodes that will bootstrap itself into a single-node cluster, which all the other nodes will then join. This simple approach is not resilient to failures until the other master-eligible nodes have joined the cluster. For example, if you have a master-eligible node with [node name](../../deploy/self-managed/important-settings-configuration.md#node-name) `master-a` then configure it as follows (omitting `cluster.initial_master_nodes` from the configuration of all other nodes):
 
 ```yaml
@@ -45,7 +44,6 @@ cluster.initial_master_nodes:
 You must set `cluster.initial_master_nodes` to the same list of nodes on each node on which it is set in order to be sure that only a single cluster forms during bootstrapping. If `cluster.initial_master_nodes` varies across the nodes on which it is set then you may bootstrap multiple clusters. It is usually not possible to recover from this situation without losing data.
 ::::
 
-
 ::::{admonition} Node name formats must match
 :name: modules-discovery-bootstrap-cluster-fqdns
 
@@ -62,12 +60,10 @@ This message shows the node names `master-a.example.com` and `master-b.example.c
 
 ::::
 
-
 ## Choosing a cluster name [bootstrap-cluster-name]
 
 The [`cluster.name`](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/configuration-reference/miscellaneous-cluster-settings.md#cluster-name) setting enables you to create multiple clusters which are separated from each other. Nodes verify that they agree on their cluster name when they first connect to each other, and Elasticsearch will only form a cluster from nodes that all have the same cluster name. The default value for the cluster name is `elasticsearch`, but it is recommended to change this to reflect the logical name of the cluster.
 
-
 ## Auto-bootstrapping in development mode [bootstrap-auto-bootstrap]
 
 By default each node will automatically bootstrap itself into a single-node cluster the first time it starts. If any of the following settings are configured then auto-bootstrapping will not take place:
@@ -100,6 +96,3 @@ If you intended to form a new multi-node cluster but instead bootstrapped a coll
 6. Remove `cluster.initial_master_nodes` from every node’s configuration.
 
 ::::
-
-
-

deploy-manage/distributed-architecture/discovery-cluster-formation/modules-discovery-quorums.md

@@ -20,15 +20,12 @@ If you stop half or more of the nodes in the voting configuration at the same ti
 
 ::::
 
-
 After a master-eligible node has joined or left the cluster the elected master may issue a cluster-state update that adjusts the voting configuration to match, and this can take a short time to complete. It is important to wait for this adjustment to complete before removing more nodes from the cluster. See [Removing master-eligible nodes](../../maintenance/add-and-remove-elasticsearch-nodes.md#modules-discovery-removing-nodes) for more information.
 
-
 ## Master elections [_master_elections]
 
 Elasticsearch uses an election process to agree on an elected master node, both at startup and if the existing elected master fails. Any master-eligible node can start an election, and normally the first election that takes place will succeed. Elections only usually fail when two nodes both happen to start their elections at about the same time, so elections are scheduled randomly on each node to reduce the probability of this happening. Nodes will retry elections until a master is elected, backing off on failure, so that eventually an election will succeed (with arbitrarily high probability). The scheduling of master elections are controlled by the [master election settings](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/configuration-reference/discovery-cluster-formation-settings.md#master-election-settings).
 
-
 ## Cluster maintenance, rolling restarts and migrations [_cluster_maintenance_rolling_restarts_and_migrations]
 
 Many cluster maintenance tasks involve temporarily shutting down one or more nodes and then starting them back up again. By default {{es}} can remain available if one of its master-eligible nodes is taken offline, such as during a rolling upgrade. Furthermore, if multiple nodes are stopped and then started again then it will automatically recover, such as during a full cluster restart. There is no need to take any further action with the APIs described here in these cases, because the set of master nodes is not changing permanently.

deploy-manage/distributed-architecture/discovery-cluster-formation/modules-discovery-voting.md

@@ -31,7 +31,6 @@ GET /_cluster/state?filter_path=metadata.cluster_coordination.last_committed_con
 The current voting configuration is not necessarily the same as the set of all available master-eligible nodes in the cluster. Altering the voting configuration involves taking a vote, so it takes some time to adjust the configuration as nodes join or leave the cluster. Also, there are situations where the most resilient configuration includes unavailable nodes or does not include some available nodes. In these situations, the voting configuration differs from the set of available master-eligible nodes in the cluster.
 ::::
 
-
 Larger voting configurations are usually more resilient, so Elasticsearch normally prefers to add master-eligible nodes to the voting configuration after they join the cluster. Similarly, if a node in the voting configuration leaves the cluster and there is another master-eligible node in the cluster that is not in the voting configuration then it is preferable to swap these two nodes over. The size of the voting configuration is thus unchanged but its resilience increases.
 
 It is not so straightforward to automatically remove nodes from the voting configuration after they have left the cluster. Different strategies have different benefits and drawbacks, so the right choice depends on how the cluster will be used. You can control whether the voting configuration automatically shrinks by using the [`cluster.auto_shrink_voting_configuration` setting](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/configuration-reference/discovery-cluster-formation-settings.md).
@@ -40,19 +39,16 @@ It is not so straightforward to automatically remove nodes from the voting confi
 If `cluster.auto_shrink_voting_configuration` is set to `true` (which is the default and recommended value) and there are at least three master-eligible nodes in the cluster, Elasticsearch remains capable of processing cluster state updates as long as all but one of its master-eligible nodes are healthy.
 ::::
 
-
 There are situations in which Elasticsearch might tolerate the loss of multiple nodes, but this is not guaranteed under all sequences of failures. If the `cluster.auto_shrink_voting_configuration` setting is `false`, you must remove departed nodes from the voting configuration manually. Use the [voting exclusions API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-post-voting-config-exclusions) to achieve the desired level of resilience.
 
 No matter how it is configured, Elasticsearch will not suffer from a "split-brain" inconsistency. The `cluster.auto_shrink_voting_configuration` setting affects only its availability in the event of the failure of some of its nodes and the administrative tasks that must be performed as nodes join and leave the cluster.
 
-
 ## Even numbers of master-eligible nodes [_even_numbers_of_master_eligible_nodes]
 
 There should normally be an odd number of master-eligible nodes in a cluster. If there is an even number, Elasticsearch leaves one of them out of the voting configuration to ensure that it has an odd size. This omission does not decrease the failure-tolerance of the cluster. In fact, improves it slightly: if the cluster suffers from a network partition that divides it into two equally-sized halves then one of the halves will contain a majority of the voting configuration and will be able to keep operating. If all of the votes from master-eligible nodes were counted, neither side would contain a strict majority of the nodes and so the cluster would not be able to make any progress.
 
 For instance if there are four master-eligible nodes in the cluster and the voting configuration contained all of them, any quorum-based decision would require votes from at least three of them. This situation means that the cluster can tolerate the loss of only a single master-eligible node. If this cluster were split into two equal halves, neither half would contain three master-eligible nodes and the cluster would not be able to make any progress. If the voting configuration contains only three of the four master-eligible nodes, however, the cluster is still only fully tolerant to the loss of one node, but quorum-based decisions require votes from two of the three voting nodes. In the event of an even split, one half will contain two of the three voting nodes so that half will remain available.
 
-
 ## Setting the initial voting configuration [_setting_the_initial_voting_configuration]
 
 When a brand-new cluster starts up for the first time, it must elect its first master node. To do this election, it needs to know the set of master-eligible nodes whose votes should count. This initial voting configuration is known as the *bootstrap configuration* and is set in the [cluster bootstrapping process](modules-discovery-bootstrap-cluster.md).
@@ -65,5 +61,4 @@ If the bootstrap configuration is not set correctly, when you start a brand-new
 To illustrate the problem with configuring each node to expect a certain cluster size, imagine starting up a three-node cluster in which each node knows that it is going to be part of a three-node cluster. A majority of three nodes is two, so normally the first two nodes to discover each other form a cluster and the third node joins them a short time later. However, imagine that four nodes were erroneously started instead of three. In this case, there are enough nodes to form two separate clusters. Of course if each node is started manually then it’s unlikely that too many nodes are started. If you’re using an automated orchestrator, however, it’s certainly possible to get into this situation-- particularly if the orchestrator is not resilient to failures such as network partitions.
 ::::
 
-
 The initial quorum is only required the very first time a whole cluster starts up. New nodes joining an established cluster can safely obtain all the information they need from the elected master. Nodes that have previously been part of a cluster will have stored to disk all the information that is required when they restart.

deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/index-level-shard-allocation.md

@@ -3,31 +3,12 @@ mapped_urls:
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-allocation.html
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/shard-allocation-filtering.html
   - https://www.elastic.co/guide/en/elasticsearch/reference/current/recovery-prioritization.html
+applies_to:
+  stack:
 ---
 
 # Index-level shard allocation
 
-% What needs to be done: Refine
-
-% Scope notes: also reference https://www.elastic.co/guide/en/elasticsearch/reference/current/allocation-total-shards.html and https://www.elastic.co/guide/en/elasticsearch/reference/current/data-tier-shard-filtering.html
-
-% Use migrated content from existing pages that map to this page:
-
-% - [ ] ./raw-migrated-files/elasticsearch/elasticsearch-reference/index-modules-allocation.md
-%      Notes: conceptual content
-% - [ ] ./raw-migrated-files/elasticsearch/elasticsearch-reference/shard-allocation-filtering.md
-%      Notes: conceptual content
-% - [ ] ./raw-migrated-files/elasticsearch/elasticsearch-reference/recovery-prioritization.md
-%      Notes: conceptual content
-
-⚠️ **This page is a work in progress.** ⚠️
-
-The documentation team is working to combine content pulled from the following pages:
-
-* [/raw-migrated-files/elasticsearch/elasticsearch-reference/index-modules-allocation.md](../../../raw-migrated-files/elasticsearch/elasticsearch-reference/index-modules-allocation.md)
-* [/raw-migrated-files/elasticsearch/elasticsearch-reference/shard-allocation-filtering.md](../../../raw-migrated-files/elasticsearch/elasticsearch-reference/shard-allocation-filtering.md)
-* [/raw-migrated-files/elasticsearch/elasticsearch-reference/recovery-prioritization.md](../../../raw-migrated-files/elasticsearch/elasticsearch-reference/recovery-prioritization.md)
-
 In Elasticsearch, per-index settings allow you to control the allocation of shards to nodes through index-level shard allocation settings. These settings enable you to specify preferences or constraints for where shards of a particular index should reside. This includes allocating shards to nodes with specific attributes or avoiding certain nodes. This level of control helps optimize resource utilization, balance load, and ensure data redundancy and availability according to your deployment's specific requirements. In addition to the content in this article, there are additional resources:
 
 * [Shard allocation filtering](../../../deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/index-level-shard-allocation.md): Controlling which shards are allocated to which nodes.
@@ -45,8 +26,7 @@ The `cluster.routing.allocation` settings are dynamic, enabling existing indices
 
 For example, you could use a custom node attribute to indicate a node’s performance characteristics and use shard allocation filtering to route shards for a particular index to the most appropriate class of hardware.
 
-
-### Enabling index-level shard allocation filtering [index-allocation-filters] 
+### Enabling index-level shard allocation filtering [index-allocation-filters]
 
 To filter based on a custom node attribute:
 
@@ -89,39 +69,25 @@ To filter based on a custom node attribute:
 
 ### Index allocation filter settings [index-allocation-settings]
 
-`index.routing.allocation.include.{{attribute}}`
-:   Assign the index to a node whose `{{attribute}}` has at least one of the comma-separated values.
-
-`index.routing.allocation.require.{{attribute}}`
-:   Assign the index to a node whose `{{attribute}}` has *all* of the comma-separated values.
-
-`index.routing.allocation.exclude.{{attribute}}`
-:   Assign the index to a node whose `{{attribute}}` has *none* of the comma-separated values.
+| Setting | Description |
+|---|---|
+|`index.routing.allocation.include.{{attribute}}`| Assign the index to a node whose `{{attribute}}` has at least one of the comma-separated values.|
+|`index.routing.allocation.require.{{attribute}}`| Assign the index to a node whose `{{attribute}}` has *all* of the comma-separated values.|
+|`index.routing.allocation.exclude.{{attribute}}`| Assign the index to a node whose `{{attribute}}` has *none* of the comma-separated values. |
 
 The index allocation settings support the following built-in attributes:
 
-`_name`
-:   Match nodes by node name
-
-`_host_ip`
-:   Match nodes by host IP address (IP associated with hostname)
-
-`_publish_ip`
-:   Match nodes by publish IP address
-
-`_ip`
-:   Match either `_host_ip` or `_publish_ip`
-
-`_host`
-:   Match nodes by hostname
-
-`_id`
-:   Match nodes by node id
-
-`_tier`
-:   Match nodes by the node’s [data tier](../../../manage-data/lifecycle/data-tiers.md) role. For more details see [data tier allocation filtering](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/index-settings/data-tier-allocation-settings.md)
-
-::::{note} 
+| Attribute | Description|
+| --- | --- |
+|`_name`| Match nodes by node name |
+|`_host_ip`| Match nodes by host IP address (IP associated with hostname) |
+|`_publish_ip`| Match nodes by publish IP address |
+|`_ip`| Match either `_host_ip` or `_publish_ip` |
+| `_host`| Match nodes by hostname |
+|`_id`| Match nodes by node id |
+|`_tier`| Match nodes by the node’s [data tier](../../../manage-data/lifecycle/data-tiers.md) role. For more details see [data tier allocation filtering](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/index-settings/data-tier-allocation-settings.md) |
+
+::::{note}
 `_tier` filtering is based on [node](asciidocalypse://docs/elasticsearch/docs/reference/elasticsearch/configuration-reference/node-settings.md) roles. Only a subset of roles are [data tier](../../../manage-data/lifecycle/data-tiers.md) roles, and the generic [data role](../../../deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles.md#data-node-role) will match any tier filtering.
 ::::
 
@@ -180,4 +146,4 @@ PUT index_4/_settings
 {
   "index.priority": 1
 }
-```
+```