Sniffing should only find non-master-only nodes

[andrewvc]

Currently the sniffer searches for all nodes. However, in a cluster with dedicated master nodes this is not desirable! The ruby client behavior should do something similar to what the Transport client does here.

There is, by the way, one deficiency with the transport client, in that it ONLY adds nodes with data enabled. We should also have this match master: false nodes.

[karmi]

Currently the sniffer searches for all nodes. However, in a cluster with dedicated master nodes this is not desirable

Yes, absolutely, we should add this.

We should also have this match master: false nodes.

Not really sure -- I guess we don't want to add any potential "client" and "tribe" nodes to the pool?

[andrewvc]

@karmi I was thinking we actually would want to add client nodes, but now I see that you're correct and we shouldn't.

In the event that a user is using client nodes as load balancers and avoid having the reduce phase of search be executed on data nodes, it'd be great to add them. However, if they're using client nodes as part of an app that'd be bad.

So, I think we should do what the main transport client does and just hit data nodes for now since we can't make a distinction there.

[GlenRSmith]

Maybe the right thing to do is to have sniffing include the attributes of discovered nodes on which it makes sense to filter them from use by clients. Then any client implementation can do exactly that. Once that interface is available, then maybe a standard language client feature providing some syntactic sugar around it could be added.

[karmi]

@GlenRSmith, I think a dedicated "feature" like this would put some unnecessary load on the ES core, but a twist on the idea would be to revisit the ES core code from the perspective of client sniffing, making sure it plays nice...

[picandocodigo]

Closing this particular issue. If still required, this is a discussion that should be held in the entire Clients team for all clients.