...

file = if ${user.home}/.ignitecfg exists
           ${user.home}/.igniterc
       else if ${system.default}/.ignitecfg exists
           ${system.default}/.ignitercignitecfg
       else
           None

if file is None {
    libsDir = ${user.home}/ignite-bin
    workDir = ${user.home}/ignite-work
} else {
    libsDir, workDir = read from file
}

...

A default directory structure of installing Ignite 3.0.1 and then upgrading to Ignite 3.0.2 will look as follows:

/
+|
+---+Library/Ignite                 ignite
|    +|                                 +|
|    +---+-3.0.1                        |
|    |    +|                            |
|    |    +---+-ignite-3.0.1            |
|    |                                 |
|    +---+-3.0.2                        |
|         +|                            |
|         +---+-ignite-3.0.2 <----------+
|
+---+-Users/John
     +|
     +---+-ignite-bin
     |    +|
     |    +---+-3.0.1
     |    |    +|
     |    |    +---+-ignite-core-3.0.1.jar
     |    |    |
     |    |    +---+-plugin-cli-0.0.1.jar
     |    |
     |    +---+3.0.2
     |         +|
     |         +---+-ignite-core-3.0.2.jar
     |         |
     |         +---+-plugin-cli-0.0.1.jar
     |
     +---+-ignite-work
          +|
          +----+ignite.modules={ignite-core,plugin-cli:0.0.1}
          |
          +---+-ignite.classpath={ignite-core-3.0.2.jar:plugin-cli-0.0.1.jar}

Running Ignite

Unlike 2.x ignite.sh script, the ignite run command will start Ignite

...

node in a separate process without attaching it to the current terminal. This is done to simplify the node management and support interactive REPL mode for ignite. If no modules are installed (the default set is missing), the run command will report an error asking the user to install the modules first (this is done intentionally to prevent accidental downloads and internet access attempts on production servers).

Starting a new Ignite node may require some local initialization to have an ability to set up node-local properties and create local metastorage. The initialization will be performed via a local command and will take the node consistent ID. Similarly, the ignite run command will require the node consistent ID. If the node metastorage is not initialized, the run command will initialize it with defaults and run the node; if it is initialized, the node will be started with existing metastorage.TBD

Cluster and local commands, management endpoint

...

• easy implementation of all cluster commands at once which will solely require a list of available endpoints and arguments format
• command and argument autocompletion with possible autocompletion for dynamic arguments (for example, auto-complete node consistent ID for the ignite baseline command)
• the ability for a user to programmatically manage Ignite cluster from any platform/tool supporting HTTP (e.g. curl)

Pluggable commands

The ignite utility should be extensible and allow plugging additional commands (both cluster and local). Upon the utility startup, it will scan the ${libsDir}/${version} folder for files with -cli suffix and search such files for command definitions. This allows a user to install additional commands using the same ignite install command. 

Risks and Assumptions

Proposed changes will require one time re-setup of Apache Ignite instance as well as constructing updated ignite.sh run command.
Next version upgrade will require only running the same ignite.sh run command from new version binaryAfter installing ignite, a user will still need one-time access to the internet to download the rest of the libraries. This, however, carries low risk as the initial setup can be performed either via curl <link_to_ignite> && ./ignite install command or a custom packed .sh script which will execute the install command after download.

Discussion Links

Development list: IEP-52: Binary Delivery & Upgradability Enhancements

...