...

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

     “node3”: [“data”]

}

GET /api/cluster/roles?node=node1

[“overseer”]

GET /api/cluster/roles?role=data

["node2", "node3"]

Internal representation in ZK

This is where the roles are internally published for anyone who wishes to see this.

/roles.json

{

“overseer” : [“node1”, “node2],

“data” : [“node1”, “node2”]

...

TBD

• Implementation details like these can be fleshed out in the PR
• "roles.json"  already exists for this purpose, we can also consider adding roles as metadata for each entry in the live_nodes  list.

Other notes

• 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 started with a -Dnode.roles parameter that doesn't have a data role, 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.

...