Motivation

Ignite provide many ways to execute user provided code:

• Compute jobs.
• Services.
• SQL UDF.
• CacheInterceptors
• Query filters
• etc.

Currently, Ignite provides several ways to load user-provided code:

• add user jars to Ignite server node classpath.
• Configure DeploymentSpi implementation via IgniteConfiguration#setDeploymentSpi, IgniteConfiguration#setDeploymentMode.
  Monitored by GridDeploymentInfo, UriDeploymentSpiMBean, LocalDeploymentSpiMBean.
• Add dependencies to client node and enable peer to peer class loading.

However, all this ways lack several crucial features:

• Clear way to know which classes loaded from which nodes.
  It expected that all classes will be the same on all nodes, which is not alway true.
• Tools to view jars available.
• Clear way to update user jars.
• Having several versions of user jars: blue-green, canary deployments.
• Remove classes from Ignite process.
• Restrictions (security) for client nodes to provide classes.
  In real world cases not all client nodes can be treated as trusted
  so in many production cluster p2p class loading disabled and forbidden to enable.

We must reinvent the way Ignite loads user classes to fill the gap. 

Description

// Provide the design of the solution.

Risks and Assumptions

// Describe project risks, such as API or binary compatibility issues, major protocol changes, etc.

Discussion Links

// Links to discussions on the devlist, if applicable.

Reference Links

// Links to various reference documents, if applicable.

Tickets

// Links or report with relevant JIRA tickets.