[float]
[[breaking_70_discovery_changes]]
=== Discovery changes

[float]
==== Cluster bootstrapping is required if discovery is configured

The first time a cluster is started, `cluster.initial_master_nodes` must be set
to perform cluster bootstrapping. It should contain the names of the
master-eligible nodes in the initial cluster and be defined on every
master-eligible node in the cluster. See <<discovery-settings,the discovery
settings summary>> for an example, and the
<<modules-discovery-bootstrap-cluster,cluster bootstrapping reference
documentation>> describes this setting in more detail.

The `discovery.zen.minimum_master_nodes` setting is permitted, but ignored, on
7.x nodes.

[float]
==== Removing master-eligible nodes sometimes requires voting exclusions

If you wish to remove half or more of the master-eligible nodes from a cluster,
you must first exclude the affected nodes from the voting configuration using
the <<modules-discovery-adding-removing-nodes,voting config exclusions API>>.
If you remove fewer than half of the master-eligible nodes at the same time,
voting exclusions are not required.  If you remove only master-ineligible nodes
such as data-only nodes or coordinating-only nodes, voting exclusions are not
required. Likewise, if you add nodes to the cluster, voting exclusions are not
required.

[float]
==== Discovery configuration is required in production

Production deployments of Elasticsearch now require at least one of the
following settings to be specified in the `elasticsearch.yml` configuration
file:

- `discovery.seed_hosts`
- `discovery.seed_providers`
- `cluster.initial_master_nodes`

[float]
==== New name for `no_master_block` setting

The `discovery.zen.no_master_block` setting is now known as
`cluster.no_master_block`. Any value set for `discovery.zen.no_master_block` is
now ignored. You should remove this setting and, if needed, set
`cluster.no_master_block` appropriately after the upgrade.

[float]
==== Reduced default timeouts for fault detection

By default the <<cluster-fault-detection,cluster fault detection>> subsystem
now considers a node to be faulty if it fails to respond to 3 consecutive
pings, each of which times out after 10 seconds. Thus a node that is
unresponsive for longer than 30 seconds is liable to be removed from the
cluster. Previously the default timeout for each ping was 30 seconds, so that
an unresponsive node might be kept in the cluster for over 90 seconds.