[
https://issues.apache.org/jira/browse/IGNITE-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-14871:
-----------------------------------------
Description:
According to the
[IEP|https://cwiki.apache.org/confluence/display/IGNITE/IEP-77%3A+Node+Join+Protocol+and+Initialization],
we are going to have some new CLI commands:
h3. Cluster initialization
h4. Proposed API
{code:bash}
./ignite cluster init --node-endpoint=??? --metastorage-nodes=???
[---cmg-nodes=???]
{code}
* {{--node-endpoint}} - address of the REST endpoint of the receiving node in
host:port format
* {{--metastorage-nodes}} - space-separated list of addresses of the nodes that
will host the Metastorage Raft group. If the "--cmg-nodes" parameter is empty,
the same nodes will also host the Cluster Management Raft group.
* {{--cmg-nodes}} - space-separated list of addresses of the nodes that will
host the Cluster Management Raft group (optional parameter)
h4. Description
The purpose of this command is to deliver the initial cluster settings. The
recipient node should propagate this message to the specified nodes, so that
they will start the corresponding Raft groups. In case some nodes are
inaccessible or the Raft groups are already started, an error message should be
returned and the command must fail.
was:
When a node enters the cluster, its configuration needs to be validated in
order to maintain cluster-wide invariants and to prohibit a non-compatible or
malicious node from entering the topology.
h2. Possible approaches
h3. Remote validation
The entering node sends some metadata (e.g. its version) to a random remote
node, which validates the metadata and issues the permit for the node to join.
*Pros:*
* Possibly better security: a malicious node would have to imitate valid
requirements.
*Cons:*
* Harder to maintain backwards compatibility: old nodes need to predict what
information a new node might send.
h3. Local validation
The entering node collects some metadata from a random remote node and decides
whether it is able to join the cluster or not.
*Pros:*
* Easier to maintain backwards-compatibility: a new node knows if older nodes
are compatible with it.
* Modular validation architecture: each plugin can independently register its
cluster state requirements.
*Cons:*
* Possible security issues: a malicious node can enter the cluster more
easily. However, this may be mitigated by signing the handshake messages.
> Add cluster initialization commands to the Ignite CLI
> -----------------------------------------------------
>
> Key: IGNITE-14871
> URL: https://issues.apache.org/jira/browse/IGNITE-14871
> Project: Ignite
> Issue Type: Task
> Components: networking
> Reporter: Vyacheslav Koptilin
> Priority: Major
> Labels: ignite-3
>
> According to the
> [IEP|https://cwiki.apache.org/confluence/display/IGNITE/IEP-77%3A+Node+Join+Protocol+and+Initialization],
> we are going to have some new CLI commands:
> h3. Cluster initialization
> h4. Proposed API
> {code:bash}
> ./ignite cluster init --node-endpoint=??? --metastorage-nodes=???
> [---cmg-nodes=???]
> {code}
> * {{--node-endpoint}} - address of the REST endpoint of the receiving node in
> host:port format
> * {{--metastorage-nodes}} - space-separated list of addresses of the nodes
> that will host the Metastorage Raft group. If the "--cmg-nodes" parameter is
> empty, the same nodes will also host the Cluster Management Raft group.
> * {{--cmg-nodes}} - space-separated list of addresses of the nodes that will
> host the Cluster Management Raft group (optional parameter)
> h4. Description
> The purpose of this command is to deliver the initial cluster settings. The
> recipient node should propagate this message to the specified nodes, so that
> they will start the corresponding Raft groups. In case some nodes are
> inaccessible or the Raft groups are already started, an error message should
> be returned and the command must fail.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
