...

1. “data” role: A node with this role can host data hosting replicas. By default, this is the case for all nodes. However, if a node specifically wants no data to be hosted, it needs to have a “!data” (or “no data”) role. This ! notation is needed to unset any role that is assumed to be true by default, i.e. “data” role.
2. “overseer” role: A node with this role indicates that this node is a preferred overseer. When one or more such nodes are live, Solr guarantees that one of those nodes become the overseer.
3. “query” “coordinator” role [UPCOMING FEATURE]: This role can be associated with a node to where all queries requests can be sent, and this node sends out other remote calls to data hosting nodes, aggregates the results and sends back to user. This will be also useful for dealing with distributed query requests, bulk indexing & streaming expressions based queries. See

   Jira
   server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key SOLR-15715

   . This is very similar in concept to ElasticSearch's coordinating nodes. A coordinator node would be assumed to have no data hosted on it.
   
4. “zookeeper” role [UPCOMING FEATURE]: This role can be associated with nodes that can have embedded ZK nodes. See: https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper

...

1. Data node that can act as overseer too:
       -Dnode.roles=overseer
       -Dnode.roles=overseer,data
2. Dedicated overseer node: -Dnode.roles=overseer,!data
3. Dedicated Query Coordinator node: -Dnode.roles=query,!datacoordinator

Cluster API

As of today, there is ADDROLE and REMOVEROLE APIs to add/remove roles at run time to nodes. It supports only OVERSEERROLE. We propose to deprecate this API, and recommend users to use startup params for achieving the same. Supporting both ways is tricky and will lead to a lot of confusion among users.

Example scenario

There's a Solr cluster with the following:

* Layer1: There are about 100 nodes, each node has many data replicas.
* Layer2: To manage such a large cluster reliably, they keep aside 4-5 dedicated overseer nodes.
* Layer3: Since query aggregations/coordination can potentially be expensive, they keep aside 5-10 query nodes.

Proposing the roles as:
* Layer1 nodes are the "data nodes" and hence get either no role defined for them or -Dnode.roles=data.
* Layer2 nodes are "overseer nodes" (though, only one of them can be an overseer at a time). They get -Dnode.roles=!data,overseer
* Layer3 nodes are "coordinator nodes", no data must be hosted on these nodes and they are started with -Dnode.roles=coordinator

How to Retrieve Roles?

Public API

...

     “node2”: [“overseer”, “data”“!data”],

     “node3”: [“data”]

}

...

• Every time a node starts up with specified roles, the node assumes it is the correct role for that node and publishes those roles in ZK after successful startup.
• If a node is being assigned a !data role via startup parameter, but it already has data hosting replicas on it, the startup fails with an error (and a hint indicating how to move replicas away from this replica).
• If a coordinator node is started with "data" role also, it fails to startup with a message indicating a node cannot both be coordinator and data node.

Compatibility, Deprecation, and Migration Plan

...