Use default discovery implementation for single-node discovery #40036
Conversation
ywelsch
added
>enhancement
v7.0.0
:Distributed Coordination/Cluster Coordination
|
Pinging @elastic/es-distributed |
There was a problem hiding this comment.
I think we can improve our handling of the case where this node used to be part of a larger cluster and has since been restarted in single-node mode, in which it will no longer be able to form a cluster. For instance, the Coordinator could check this in doStart() and throw an exception if it'll never obtain a quorum.
I think we should also refuse to start if node.master: false.
I think both of the above need a mention in the breaking changes docs.
I would also like to reject (edit - see below)PeersRequests from other nodes; today we respond normally and this means that other nodes' ClusterFormationFailureHelpers will report that they have "discovered" this node (in amongst all the exceptions about being unable to join it).
server/src/main/java/org/elasticsearch/cluster/coordination/ClusterBootstrapService.java
Show resolved
Hide resolved
| logger.trace("handleJoinRequest: as {}, handling {}", mode, joinRequest); | ||
|
|
||
| if (singleNodeDiscovery && joinRequest.getSourceNode().equals(getLocalNode()) == false) { | ||
| joinCallback.onFailure(new IllegalStateException("cannot join node with single-node discovery")); |
There was a problem hiding this comment.
Suggest cannot join node with [discovery.type] set to [single-node] so that it's clearer what setting to look for.
Rejecting |
It's an extra check in Coordinator for a super-edge case. I'm not sure how much that buys us (additional code to maintain vs slightly better error reporting), so just want to ask again if you think this is really worth pursuing.
Again, extra check for an edge case, and covered by
I disagree and think this should be treated as a bug fix. |
Yes, I think the improvement in the error reporting is worth it. Bootstrap checks continue to cause confusion, and if someone tries to disable the bootstrap checks by moving to single-node discovery after the cluster has formed in development mode then I think that keeping the node running despite a hopeless situation is going to add to the confusion.
Similarly, keeping the node running in a hopeless situation is confusing. The log message would say |
Switches "discovery.type: single-node" from using a separate implementation for single-node discovery to using the existing standard discovery implementation, with two small adaptions: - auto-bootstrapping, but requiring initial_master_nodes not to be set. - not actively pinging other nodes using the Peerfinder - not allowing other nodes to join its single-node cluster (if they have e.g. been set up using regular discovery and connect to the single-disco node).
Switches "discovery.type: single-node" from using a separate implementation for single-node discovery to using the existing standard discovery implementation, with two small adaptions: - auto-bootstrapping, but requiring initial_master_nodes not to be set. - not actively pinging other nodes using the Peerfinder - not allowing other nodes to join its single-node cluster (if they have e.g. been set up using regular discovery and connect to the single-disco node).
4 participants
Switches "discovery.type: single-node" from using a separate implementation for single-node discovery to using the existing standard discovery implementation, with two small adaptions:
initial_master_nodesnot to be set.