ID | IEP-59 | |||||||
Author | ||||||||
Sponsor | ||||||||
Created |
| |||||||
Status |
|
|
Table of Contents |
---|
REJECTED due to a IEP-103.
Currently, there are three separate mechanisms for code deployment:
...
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:
...
Code Block | ||
---|---|---|
| ||
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).
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.
N/Ahttp://apache-ignite-developers.2346864.n4.nabble.com/JAR-based-code-deployment-td49366.html
N/A
...