REJECTED due to a IEP-103.


Currently, there are three separate mechanisms for code deployment:

  1. Static deployment of JARs under the IGNITE_HOME/libs  folder.
  2. Peer class loading:
  3. DeploymentSpi :

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.


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


The DeploymentSpi (or a similar mechanism) can be kept in place, as long as it reuses the same deployment engine. This will allow users to deploy classes to an FTP/shared FS/S3 storage so that those classes are automatically picked up by the nodes. This can be a convenient alternative to explicit deployment from the command line. However, the internals must be reused (i.e. updating files in the storage is equivalent to invoking the ignitectl deploy command).

Risks and Assumptions

The new approach implies the removal of the 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 an initial evaluation of Ignite.

Discussion Links

Reference Links




  • No labels