Class DesiredNodes

java.lang.Object
org.elasticsearch.cluster.metadata.DesiredNodes
All Implemented Interfaces:
Iterable<DesiredNodeWithStatus>, Writeable, ToXContent, ToXContentObject

public class DesiredNodes extends Object implements Writeable, ToXContentObject, Iterable<DesiredNodeWithStatus>

Desired nodes represents the cluster topology that the operator of the cluster is aiming for. Therefore, it is possible that the desired nodes contain nodes that are not part of the cluster in contrast to DiscoveryNodes that contains only nodes that are part of the cluster.

This concept is useful as it provides more context about future topology changes to the system as well as the desired set of nodes in the cluster, allowing it to make better decisions about allocation, autoscaling, auto-expand replicas, etc.

Additionally, settings validation is done during desired nodes updates avoiding boot-looping when an invalid setting is provided before the node is started.

To modify the desired nodes it is necessary to provide the entire collection of nodes that will be part of the proposed cluster topology.

Desired nodes are expected to be part of a lineage defined by the provided historyId. The historyId is provided by the orchestrator taking care of managing the cluster. In order to identify the different proposed desired nodes within the same history, it is also expected that the orchestrator provides a monotonically increasing version when it communicates about future topology changes. The cluster rejects desired nodes updated with a version less than or equal than the current version for the same historyId.

The historyId is expected to remain stable during the cluster lifecycle, but it is possible that the orchestrator loses its own state and needs to be restored to a previous point in time with an older desired nodes version. In those cases it is expected to use new historyId that would allow starting from a different version.

Each DesiredNode part of DesiredNodes has a DesiredNodeWithStatus.Status depending on whether or not the node has been part of the cluster at some point.

The two possible statuses DesiredNodeWithStatus.Status are:
  • PENDING: The DesiredNode is not part of the cluster yet
  • ACTUALIZED: The DesiredNode is or has been part of the cluster. Notice that it is possible that a node has ACTUALIZED status but it is not part of DiscoveryNodes, this is a conscious decision as it is expected that nodes can leave the cluster momentarily due to network issues, gc pressure, restarts, hardware failures etc, but are expected to still be part of the cluster.

See NodeJoinExecutor and TransportUpdateDesiredNodesAction for more details about desired nodes status tracking.

Finally, each DesiredNode is expected to provide a way of identifying the node when it joins, Node.NODE_EXTERNAL_ID_SETTING allows providing that identity through settings.