-
Notifications
You must be signed in to change notification settings - Fork 25.8k
Validate build hash of joining node #65249
Copy link
Copy link
Closed
Labels
:Distributed/Cluster CoordinationCluster formation and cluster state publication, including cluster membership and fault detection.Cluster formation and cluster state publication, including cluster membership and fault detection.>enhancementTeam:DistributedMeta label for distributed team.Meta label for distributed team.
Metadata
Metadata
Assignees
Labels
:Distributed/Cluster CoordinationCluster formation and cluster state publication, including cluster membership and fault detection.Cluster formation and cluster state publication, including cluster membership and fault detection.>enhancementTeam:DistributedMeta label for distributed team.Meta label for distributed team.
Type
Fields
Give feedbackNo fields configured for issues without a type.
Today our more intrepid users sometimes form a cluster from unreleased versions in order to test out new functionality. This is usually fine, and indeed is encouraged, but can lead to difficulties if they happen to use two different builds of the same numbered version since there is no guarantee of compatibility between such builds. Clusters like this can behave quite strangely and it can be tricky to work out why. A similar issue occurs when using a remote cluster with an equal version but a different build hash.
I'm opening this issue to discuss whether we should prevent an invalid mix of nodes from forming a faulty cluster or remote cluster connection by sharing
Build.CURRENT.hash()as well asVersion.CURRENTsomewhere in the handshaking process. If two nodes determine that they have the same numbered version, but a different build hash, then they would emit a warning and drop the connection.