ID | IEP-59 |
Author | Valentin Kulichenko |
Sponsor | Valentin Kulichenko |
Created |
|
Status | DRAFT |
Currently, there are three separate mechanisms for code deployment:
IGNITE_HOME/libs
folder.DeploymentSpi
: https://apacheignite.readme.io/docs/deployment-spiHaving 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:
.class
files.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 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.
N/A
N/A
N/A