[DOCS] adapt docs to node.client setting removal

docs/java-api/client.asciidoc

@@ -83,9 +83,11 @@ the nodes listed and connected. Defaults to `5s`.
 
 
 [[client-connected-to-client-node]]
-=== Connecting a Client to a Client Node
+=== Connecting a Client to a Coordinating Only Node
 
-You can start locally a {ref}/modules-node.html#client-node[Client Node] and then simply create
+You can start locally a {ref}/modules-node.html#coordinating-only-node[Coordinating Only Node]
-a <<transport-client,`TransportClient`>> in your application which connects to this Client Node.
+and then simply create a <<transport-client,`TransportClient`>> in your
+application which connects to this Coordinating Only Node.
 
-This way, the client node will be able to load whatever plugin you need (think about discovery plugins for example).
+This way, the coordinating only node will be able to load whatever plugin you
+need (think about discovery plugins for example).

docs/plugins/ingest.asciidoc

@@ -1,7 +1,7 @@
 [[ingest]]
 == Ingest Plugins
 
-The ingest plugins extend Elaticsearch by providing additional ingest node capabilities.
+The ingest plugins extend Elasticsearch by providing additional ingest node capabilities.
 
 [float]
 === Core Ingest Plugins

docs/reference/modules/discovery/zen.asciidoc

@@ -56,16 +56,13 @@ serves as a protection against (partial) network failures where node may unjustl
 think that the master has failed. In this case the node will simply hear from
 other nodes about the currently active master.
 
-If `discovery.zen.master_election.filter_client` is `true`, pings from client nodes (nodes where `node.client` is
+If `discovery.zen.master_election.filter_client` is `true`, pings from nodes where both `node.data` and
-`true`, or both `node.data` and `node.master` are `false`) are ignored during master election; the default value is
+`node.master` are set to false `false` are ignored during master election; the default value is `true`.
-`true`. If `discovery.zen.master_election.filter_data` is `true`, pings from non-master-eligible data nodes (nodes
+If `discovery.zen.master_election.filter_data` is `true`, pings from non-master-eligible data nodes (nodes
 where `node.data` is `true` and `node.master` is `false`) are ignored during master election; the default value is
 `false`. Pings from master-eligible nodes are always observed during master election.
 
-Nodes can be excluded from becoming a master by setting `node.master` to
+Nodes can be excluded from becoming a master by setting `node.master` to `false`.
-`false`. Note, once a node is a client node (`node.client` set to
-`true`), it will not be allowed to become a master (`node.master` is
-automatically set to `false`).
 
 The `discovery.zen.minimum_master_nodes` sets the minimum
 number of master eligible nodes that need to join a newly elected master in order for an election to

docs/reference/modules/node.asciidoc

@@ -27,23 +27,21 @@ the cluster.
 A node that has `node.data` set to `true` (default). Data nodes hold data and
 perform data related operations such as CRUD, search, and aggregations.
 
-<<client-node,Client node>>::
+<<ingest,Ingest node>>::
 
-A client node has both `node.master` and `node.data` set to `false`. It can
+A node that has `node.ingest` set to `true` (default). Ingest nodes can be
-neither hold data nor become the master node.  It behaves as a ``smart
+used to pre-process documents before the actual indexing takes place.
-router'' and is used to forward cluster-level requests to the master node and
-data-related requests (such as search) to the appropriate data nodes.
 
 <<modules-tribe,Tribe node>>::
 
 A tribe node, configured via the `tribe.*` settings, is a special type  of
-client node that can connect to multiple clusters and perform search and other
+coordinating only node that can connect to multiple clusters and perform
-operations across all connected clusters.
+search and other operations across all connected clusters.
 
-By default a node is both a master-eligible node and a data node. This is very
+By default a node is a master-eligible node and a data node, plus it can
-convenient for small clusters but, as the cluster grows, it becomes important
+pre-process documents through ingest pipelines. This is very convenient for
-to consider separating dedicated master-eligible nodes from dedicated data
+small clusters but, as the cluster grows, it becomes important to consider
-nodes.
+separating dedicated master-eligible nodes from dedicated data nodes.
 
 [NOTE]
 [[coordinating-node]]
@@ -61,8 +59,11 @@ returns its results to the coordinating node. In the _gather_  phase, the
 coordinating node reduces each data node's results into a single global
 resultset.
 
-This means that a _client_ node needs to have enough memory and CPU in order to
+Every node is implicitly a coordinating node. This means that a node that has
-deal with the gather phase.
+all three `node.master`, `node.data` and `node.ingest` set to `false` will
+only act as a coordinating node, which cannot be disabled. As a result, such
+a node needs to have enough memory and CPU in order to deal with the gather
+phase.
 
 ===============================================
 
@@ -96,9 +97,11 @@ To create a standalone master-eligible node, set:
 -------------------
 node.master: true <1>
 node.data: false <2>
+node.ingest: false <3>
 -------------------
 <1> The `node.master` role is enabled by default.
 <2> Disable the `node.data` role (enabled by default).
+<3> Disable the `node.ingest` role (enabled by default).
 
 [float]
 [[split-brain]]
@@ -177,40 +180,65 @@ To create a dedicated data node, set:
 -------------------
 node.master: false <1>
 node.data: true <2>
+node.ingest: false <3>
 -------------------
 <1> Disable the `node.master` role (enabled by default).
 <2> The `node.data` role is enabled by default.
+<3> Disable the `node.ingest` role (enabled by default).
 
 [float]
-[[client-node]]
+[[node-ingest-node]]
-=== Client Node
+=== Ingest Node
 
-If you take away the ability to be able to handle master duties and take away
+Ingest nodes can execute pre-processing pipelines, composed of one or more
-the ability to hold data, then you are left with a _client_ node that can only
+ingest processors. Depending on the type of operations performed by the ingest
-route requests, handle the search reduce phase, and distribute bulk indexing.
+processors and the required resources, it may make sense to have dedicated
-Essentially, client nodes behave as smart load balancers.
+ingest nodes, that will only perform this specific task.
 
-Standalone client nodes can benefit large clusters by offloading the
+To create a dedicated ingest node, set:
-coordinating node role from data and master-eligible nodes.  Client nodes join
-the cluster and receive the full <<cluster-state,cluster state>>, like every
-other node, and they use the cluster state to route requests directly to the
-appropriate place(s).
-
-WARNING: Adding too many client nodes to a cluster can increase the burden on
-the entire cluster because the elected master node must await acknowledgement
-of cluster state updates from every node! The benefit of client nodes should
-not be overstated -- data nodes can happily serve the same purpose as client
-nodes.
-
-To create a deciated client node, set:
 
 [source,yaml]
 -------------------
 node.master: false <1>
 node.data: false <2>
+node.ingest: true <3>
 -------------------
 <1> Disable the `node.master` role (enabled by default).
 <2> Disable the `node.data` role (enabled by default).
+<3> The `node.ingest` role is enabled by default.
+
+[float]
+[[coordinating-only-node]]
+=== Coordinating only node
+
+If you take away the ability to be able to handle master duties, to hold data,
+and pre-process documents, then you are left with a _coordinating_ node that
+can only route requests, handle the search reduce phase, and distribute bulk
+indexing. Essentially, coordinating only nodes behave as smart load balancers.
+
+Coordinating only nodes can benefit large clusters by offloading the
+coordinating node role from data and master-eligible nodes.  They join the
+cluster and receive the full <<cluster-state,cluster state>>, like every other
+node, and they use the cluster state to route requests directly to the
+appropriate place(s).
+
+WARNING: Adding too many coordinating only nodes to a cluster can increase the
+burden on the entire cluster because the elected master node must await
+acknowledgement of cluster state updates from every node! The benefit of
+coordinating only nodes should not be overstated -- data nodes can happily
+serve the same purpose.
+
+To create a coordinating only node, set:
+
+[source,yaml]
+-------------------
+node.master: false <1>
+node.data: false <2>
+node.ingest: false <3>
+-------------------
+<1> Disable the `node.master` role (enabled by default).
+<2> Disable the `node.data` role (enabled by default).
+<3> Disable the `node.ingest` role (enabled by default).
 
 [float]
 == Node data path settings
@@ -259,7 +287,7 @@ setting to the `elasticsearch.yml` config file:
 node.max_local_storage_nodes: 1
 ------------------------------
 
-WARNING: Never run different node types (i.e. master, data, client) from the
+WARNING: Never run different node types (i.e. master, data) from the
 same data directory. This can lead to unexpected data loss.
 
 [float]