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

Nodes types filters order not kept for _nodes API #41885

Closed
fpompermaier opened this issue May 7, 2019 · 6 comments · Fixed by #42045
Closed

Nodes types filters order not kept for _nodes API #41885

fpompermaier opened this issue May 7, 2019 · 6 comments · Fixed by #42045
Labels
>bug :Distributed Coordination/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. v7.2.0 v8.0.0-alpha1

Comments

@fpompermaier
Copy link
Contributor

In the cluster API the following NOTE is wrong (I think):

node filters run in the order in which they are given, which is important if using filters that remove nodes from the set. For example _all,master:false means all the nodes except the master-eligible ones, but master:false,_all means the same as _all because the _all filter runs after the master:false filter.

It should be:

node filters run in the order in which they are given, which is important if using filters that remove nodes from the set. For example _all,master:false means all the nodes except the master-eligible ones, but master:false,_all means the same as master:false because the _all filter runs after the master:false filter.

@astefan astefan added >docs General docs changes :Distributed Coordination/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. labels May 8, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

@astefan
Copy link
Contributor

astefan commented May 8, 2019

@fpompermaier for this one, I don't think you are right.

master: false removes from the set of nodes those that are master eligible, and _all adds back all the nodes, because _all is evaluated after master:false. It's a combination of removing master eligible nodes and adding all nodes (in this order), which means _all in the end.

@astefan
Copy link
Contributor

astefan commented May 8, 2019

Also, when putting master:false as the first filter, it's more or less a useless one because the filtering starts from an empty set of nodes and it's like removing the master eligible nodes from an empty set of nodes.

@astefan astefan closed this as completed May 8, 2019
@fpompermaier
Copy link
Contributor Author

fpompermaier commented May 8, 2019

Actually I'm trying the following requests on http://demo.elastic.co/app/kibana (7.0.0) but the documented statements are not true..

GET _nodes/_all # OK, returns all 9 nodes
GET _nodes/master:true # OK, returns all 3 master nodes
GET _nodes/master:false # OK, returns all 0 nodes
GET _nodes/_all,master:false == GET _nodes/_all
From documentation, GET _nodes/_all,master:false should be != GET _nodes/_all

Am I wrong @astefan ?

@astefan
Copy link
Contributor

astefan commented May 8, 2019

@fpompermaier you are right and we might have a bug in our code. Looking into it. And I'm re-opening this issue. Thank you for your diligence on this issue.

@astefan astefan reopened this May 8, 2019
@astefan astefan added >bug and removed >docs General docs changes labels May 8, 2019
@astefan astefan changed the title Fix cluster API documentation Nodes types filters order not kept for _nodes API May 10, 2019
@astefan
Copy link
Contributor

astefan commented May 10, 2019

This is fixed in 8.0.0 with 74a7438 and in 7.2.0 with 912c6bd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Distributed Coordination/Cluster Coordination Cluster formation and cluster state publication, including cluster membership and fault detection. v7.2.0 v8.0.0-alpha1
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants