Add GET /_cluster/master endpoint #40047
Conversation
We discussed recently that the cluster state API should be considered "internal" and therefore our usual cast-iron stability guarantees do not hold for this API. However, today there is no stable API for identifying the current master node in JSON format. The REST tests that need to do this will typically call `GET /_cluster/state` and extract the master from the response. This change introduces the `GET /_cluster/master` API endpoint to identify the current master node so that clients do not need to extract the current master from the cluster state.
DaveCTurner
added
>enhancement
:Distributed Coordination/Cluster Coordination
|
Pinging @elastic/es-distributed |
| "get cluster master": | ||
| - skip: | ||
| version: " - 7.99.99" | ||
| reason: Get cluster master API was introduced in 8.0 |
There was a problem hiding this comment.
After backporting, as a follow up, this skip can be removed, and all the REST tests that get the master ID from the cluster state can migrate to using this API instead.
|
nice, shall we add support for this new api to the high-level client as part of this PR? |
I wonder if we can just achieve the same thing with |
The node ID only appears as the (unique) key of the resulting map of nodes. I sketched a possible way to do this in #40052, but it's kinda icky. |
|
The advantage of the approach in #40052 is that the yml tests become simpler, avoiding the extra call to determine the master at the beginning of the test. I'm not sure yet whether we want to enforce uniqueness or whether we should just support a wildcard selector |
|
In fact most of the REST tests don't want the master node ID: picking an arbitrary ID (perhaps of a data node) is closer to what they want. Closing this in favour of #40052. |
We discussed recently that the cluster state API should be considered "internal" and therefore our usual cast-iron stability guarantees do not hold for this API. However, there are a good number of REST tests that try to identify the master node. Today they call `GET /_cluster/state` API and extract the master node ID from the response. In fact many of these tests just want an arbitary node ID (or perhaps a data node ID) so an alternative is to call `GET _nodes` or `GET _nodes/data:true` and obtain a node ID from the keys of the `nodes` map in the response. This change adds the ability for YAML-based REST tests to extract an arbitrary key from a map so that they can obtain a node ID from the nodes info API instead of using the master node ID from the cluster state API. Relates elastic#40047.
We discussed recently that the cluster state API should be considered "internal" and therefore our usual cast-iron stability guarantees do not hold for this API. However, there are a good number of REST tests that try to identify the master node. Today they call `GET /_cluster/state` API and extract the master node ID from the response. In fact many of these tests just want an arbitary node ID (or perhaps a data node ID) so an alternative is to call `GET _nodes` or `GET _nodes/data:true` and obtain a node ID from the keys of the `nodes` map in the response. This change adds the ability for YAML-based REST tests to extract an arbitrary key from a map so that they can obtain a node ID from the nodes info API instead of using the master node ID from the cluster state API. Relates #40047.
We discussed recently that the cluster state API should be considered
"internal" and therefore our usual cast-iron stability guarantees do not hold
for this API.
However, today there is no stable API for identifying the current master node
in JSON format. The REST tests that need to do this will typically call
GET /_cluster/stateand extract the master from the response.This change introduces the
GET /_cluster/masterAPI endpoint to identify thecurrent master node so that clients do not need to extract the current master
from the cluster state.