Motivation

Currently, there are three separate mechanisms for code deployment:

1. Static deployment of JARs under the IGNITE_HOME/libs  folder.
2. Peer class loading: https://apacheignite.readme.io/docs/zero-deployment#peer-class-loading
3. DeploymentSpi : https://apacheignite.readme.io/docs/deployment-spi

Having multiple ways is an unnecessary complication, which negatively affects usability. In addition, the peer class loading option is complicated in and of itself. It is too implicit and provides multiple modes with unclear semantics. It also doesn't work too well with dependencies.

On top of that, the documentation claims that Ignite provides "Zero Deployment", which is not entirely true. Most of the user code required on server nodes has to be statically deployed and can only be updated during restart.

Description

The proposed solution is to create a unified mechanism for code deployment, based on JAR files explicitly provided by users. A user can dynamically deploy, undeploy or redeploy code via a specialized command line tool. The options to provide the code are the following:

• A single JAR file.
• A group of JAR files.
• A folder containing JAR files and/or .class  files.
• A Maven artifact provided in the following format: groupId:artifactId:version . There should be an option to include or exclude dependencies.

Here are some of the commands that we can have on the command line tool:

ignitectl deploy <deployment-name> <URL>
ignitectl deploy <deployment-name> <groupId:artifactId:version>
ignitectl undeploy <deployment-name>
ignitectl list-deployments

Risks and Assumptions

The new approach implies the removal of peer class loading mechanism. While it comes along with fundamental issues, it seems to be used in Compute Grid use cases, where pure Zero Deployment is possible. It is also very convenient for running examples and doing initial evaluation of Ignite.

Discussion Links

N/A

Reference Links

N/A

Tickets

N/A