Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add _coordinating_only for nodes resolving in nodes API #30313

Merged
merged 9 commits into from
May 9, 2018
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions docs/reference/cluster.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -9,13 +9,15 @@
Most cluster level APIs allow to specify which nodes to execute on (for
example, getting the node stats for a node). Nodes can be identified in
the APIs either using their internal node id, the node name, address,
custom attributes, or just the `_local` node receiving the request. For
custom attributes, or just the `_local`, `_master` or `_coordinating_only` nodes receiving the request. For
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't make sense - _local refers to the node receiving the request, but _master and _coordinating_only refer to all master and coordinating nodes. I think it might be better to expand this section of the docs with something like a bulleted list, since this sentence is becoming unwieldy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @DaveCTurner, I just find this part a little bit confusing when we say "nodes to execute on" or "node receiving the request". If I understand well, all the _local, _master, _coordinating_only or node id, custom attributes etc. are just filters right ? When I do a GET /_nodes/_local it returns to me the node info of the local node, if I do a GET /_nodes/_master, it returns to me the node info of master node ? same for other api like nodes stats, nodes hot_threads etc. So if the local node is the master, I get the same result for the above 2 requests right ? What we would explain here is not "the node to which request was forwarded" ?

example, here are some sample executions of nodes info:

[source,js]
--------------------------------------------------
# Local
# Local, current master or coordinating only nodes
GET /_nodes/_local
GET /_nodes/_master
GET /_nodes/_coordinating_only
# Address
GET /_nodes/10.0.0.3,10.0.0.4
GET /_nodes/10.0.0.*
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -148,6 +148,19 @@ public ImmutableOpenMap<String, DiscoveryNode> getMasterAndDataNodes() {
return nodes.build();
}

/**
* Get a {@link Map} of the coordinating only nodes (nodes which are neither master, nor data, nor ingest nodes) arranged by their ids
*
* @return {@link Map} of the coordinating only nodes arranged by their ids
*/
public ImmutableOpenMap<String, DiscoveryNode> getCoordinatingOnlyNodes() {
ImmutableOpenMap.Builder<String, DiscoveryNode> nodes = ImmutableOpenMap.builder(this.nodes);
nodes.removeAll(masterNodes.keys());
nodes.removeAll(dataNodes.keys());
nodes.removeAll(ingestNodes.keys());
return nodes.build();
}

/**
* Get a node by its id
*
Expand Down Expand Up @@ -294,10 +307,10 @@ public DiscoveryNode resolveNode(String node) {

/**
* resolves a set of node "descriptions" to concrete and existing node ids. "descriptions" can be (resolved in this order):
* - "_local" or "_master" for the relevant nodes
* - "_local", "_master" or "_coordinating_only" for the relevant nodes
* - a node id
* - a wild card pattern that will be matched against node names
* - a "attr:value" pattern, where attr can be a node role (master, data, ingest etc.) in which case the value can be true of false
* - a "attr:value" pattern, where attr can be a node role (master, data, ingest etc.) in which case the value can be true or false,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

* or a generic node attribute name in which case value will be treated as a wildcard and matched against the node attribute values.
*/
public String[] resolveNodes(String... nodes) {
Expand All @@ -316,6 +329,8 @@ public String[] resolveNodes(String... nodes) {
if (masterNodeId != null) {
resolvedNodesIds.add(masterNodeId);
}
} else if (nodeId.equals("_coordinating_only")) {
resolvedNodesIds.addAll(getCoordinatingOnlyNodes().keys());
} else if (nodeExists(nodeId)) {
resolvedNodesIds.add(nodeId);
} else {
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -102,9 +102,7 @@ public void testCoordinatorOnlyNodes() {
.map(DiscoveryNode::getId)
.toArray(String[]::new);

assertThat(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be good to keep this assertion here too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good now, thanks 👍

discoveryNodes.resolveNodes("_all", "data:false", "ingest:false", "master:false"),
arrayContainingInAnyOrder(coordinatorOnlyNodes));
assertThat(discoveryNodes.resolveNodes("_coordinating_only"), arrayContainingInAnyOrder(coordinatorOnlyNodes));
}

public void testResolveNodesIds() {
Expand Down Expand Up @@ -254,6 +252,13 @@ Set<String> matchingNodeIds(DiscoveryNodes nodes) {
Set<String> matchingNodeIds(DiscoveryNodes nodes) {
return Collections.singleton(nodes.getMasterNodeId());
}
}, COORDINATING_ONLY("_coordinating_only") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a hangover of the previous approach - should be coordinating_only:true I think.

@Override
Set<String> matchingNodeIds(DiscoveryNodes nodes) {
Set<String> ids = new HashSet<>();
nodes.getCoordinatingOnlyNodes().keysIt().forEachRemaining(ids::add);
return ids;
}
}, MASTER_ELIGIBLE(DiscoveryNode.Role.MASTER.getRoleName() + ":true") {
@Override
Set<String> matchingNodeIds(DiscoveryNodes nodes) {
Expand Down