Page History

...

1. Cluster setup - the process of assembling a predefined set of nodes into a cluster and preparing it for the next lifecycle steps;
2. Cluster initialization - according to the Node Lifecycle description, a cluster can exist in a "zombie" state, until an "init" command is sent by the system administrator;
3. Node validation - in order to maintain the cluster configuration in a consistent state, the joining nodes should be compatible with all of the existing cluster nodes. Compatibility is ensured by validating nodes' properties, which may include some local properties (Ignite product version, Cluster Tag), as well as distributed properties from the Meta Storage.

...

1. NB: it is currently unclear what properties should be retrieved from the Meta Storage

...

1. , however, it was decided to keep this concept for possible future features implementation.

Terminology

Init command

The "init" command moves the cluster from the "zombie" state into the "active" state. It is supposed to have the following characteristics (note that the "init" command has not been specified at the moment of writing and is out of scope of this document, so all statements are approximate and can change in the future):

...

This document uses a notation of "initialized" and "empty" nodes. An initialized node is a node that has received and successfully applied the "init" command sometime in its lifetime and therefore possesses the Cluster Tag and the Meta Storage Topology version. An empty node is a node that has never received nor applied the "init" command and therefore does not possess the aforementioned properties.

...

1. Initial set of nodes is configured, including the following properties:
   1. List A subset of all nodes nodes (minimum 1, more can be specified to increase startup reliability) in the initial cluster setup (provided by the IP Finder).
2. A Join Coordinator is elected (see Join Coordinator election);
3. The Join Coordinator generates a Cluster Tag (if it hasn't already been generated);
4. All other nodes connect to the Coordinator and provide the following information:
   1. Ignite product version;
   2. Cluster Tag, if any (if a node has obtained it at any time during its life);
   3. Meta Storage Topology version, if any (if a node has obtained it at any time during its life).
5. All of the aforementioned parameters get compared with the information stored on the Coordinator, and if all of the parameters are the same, the joining node is allowed into the cluster. Otherwise, the joining node is rejected.
6. Join Coordinator adds the new node to the list of validated nodes. This can be implemented using different approaches, for example it is possible to piggyback on the current Cluster Membership implementation (ScaleCube) and to modify its transport protocol so that only valid nodes will be visible to others (similar to the implementation of the Handshake Protocol). Another way is to explicitly store and maintain a list of valid nodes in the Meta Storage.
7. If the joining node is allowed to enter the topology, it receives the following parameters from the Coordinator:
   1. Cluster Tag.

...