[ https://issues.apache.org/jira/browse/IGNITE-24035 ]


    Stanislav Lukyanov deleted comment on IGNITE-24035:
    ---------------------------------------------

was (Author: slukyanov):
PR: https://github.com/apache/ignite-3/pull/5315

> Improvement proposal: Hide CMG and Metastore Group from cluster init operation
> ------------------------------------------------------------------------------
>
>                 Key: IGNITE-24035
>                 URL: https://issues.apache.org/jira/browse/IGNITE-24035
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Aleksandr
>            Assignee: Stanislav Lukyanov
>            Priority: Major
>              Labels: ignite-3
>             Fix For: 3.1
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> h1. Motivation
> Imagine you are trying to launch an Ignite node and play with it. You've 
> downloaded the distribution and installed it with standard packaging tools. 
> Then you launched the node and entered the CLI. What's next?
> Exploring the CLI you understand that the node you've launched is
> not initialized. You run {{cluster init}} command and see the following:
> {code:java}
> [node1]> cluster init
> Missing required options: '--name=<clusterName>', '--metastorage-group=<node 
> name>'
> USAGE
>  cluster init [OPTIONS]
> DESCRIPTION
> Initializes an Ignite cluster
> OPTIONS * - required option
> *     --name=<clusterName>   Human-readable name of the cluster
> *     --metastorage-group=<node name>[,<node name>...]
>                              Metastorage group nodes (use comma-separated 
> list of node names '--metastorage-group node1, node2' to specify
>                                more than one node) that will host the Meta 
> Storage. If the --cluster-management-group option is omitted, the
>                                same nodes will also host the Cluster 
> Management Group.
>       --cluster-management-group=<node name>[,<node name>...]
>                              Names of nodes (use comma-separated list of node 
> names '--cluster-management-group node1, node2' to specify more
>                                than one node) that will host the Cluster 
> Management Group. If omitted, then --metastorage-group values will
>                                also supply the nodes for the Cluster 
> Management Group.
>       --config=<config>      Cluster configuration that will be applied 
> during the cluster initialization
>       --config-files=<file path>[,<file path>...]
>                              Path to cluster configuration files (use 
> comma-separated list of paths '--config-files path1, path2' to specify
>                                more than one file)
>       --url=<clusterUrl>     URL of cluster endpoint. It can be any node 
> URL.If not set, then the default URL from the profile settings will
>                                be used
>   -h, --help                 Show help for the specified command
>   -v, --verbose              Show additional information: logs, REST calls. 
> This flag is useful for debugging. Specify multiple options to
>                                increase verbosity for REST calls. Single 
> option shows request and response, second option (-vv) shows headers,
>                                third one (-vvv) shows body
> {code}
> Run: {{cluster init --name=i_want_it_work --metastorage-group=node1}}
> Here is the quetion: what is the "Meta Storage" and why do we need it? This 
> is something about metadata, ok. 
> But what metadata? Why I, as a user, should care about it? Should the 
> metastorage group be somehow isolated from 
> others? Should it be installed on the hardware with special requirements? So 
> many questions.
> What would be much better is to have a simple command that will initialize 
> the cluster with default settings
> (especialy for the case with one node where the choice is obvious).
> Run: {{cluster init --name=i_want_it_work}} should be enough. Even --name 
> could be optional.
> h1. Solution
> Make MS and CMG nodes parameters optional.
> If both are provided, the behavior is the same as now.
> If only one is provided, the other one uses the same value. Note: this is 
> different from the current behavior where CMG can default to MS but MS cannot 
> default to CMG because MS isn't optiona.
> If neither is provided, both are set to the same list of nodes picked 
> automatically.
> The automatic MS/CMG node choice is as follows:
>  * If cluster size <= 3, all nodes are picked.
>  * If cluster size = 4, only 3 nodes are picked. This is to avoid an even 
> number of nodes which may create split brain issues.
>  * If cluster size is >= 5, only 5 nodes are picked. We don't pick more nodes 
> because it may create unnecessary performance overhead while 5 MS/CMG create 
> sufficient failure tolerance in most use cases.
> The nodes are always picked in alphabetical order of node names. This is to 
> ensure that, given the same set of node names, we'll always initialize the 
> same way. It provides predictability of automated environments such as k8s.
> h1. What to Do
>  # Make MS and CMG lists optional on init in the internal service.
>  # Make MS and CMG lists optional in the APIs: REST, CLI, Embedded API.
>  # Update Getting Started, docs, and examples to not include MS and CMG 
> specification.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to