Motivation

...

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

Description

It proposed to add new entity to Ignite - IgniteClassPath.

IgniteClassPath properties:

• Name - unique string identifier (app_v1, 01_07_2025, etc).
• Set of libs and resources associated with IgniteClassPath.
• Each instance available on each Ignite node, maybe on demand.
• Can be created and removed runtime - without any restarts.
• Instances independent from each other.

API changes (list will be widen):

• IgniteCache#withClassPath
• IgniteCompute#withClassPath
• ServiceConfiguration#setClassPath
• JDBC driver params to point to classpath used by UDFs and other things during queries execution.
• Deprecation and removal of DeploymentSpi and related configuration properties.
• Deprecation and removal p2p class loading and related configuration properties.
• New security permission to restrict creation/

...

• deletion of IgniteClassPath for specific users.

Required tools:

• control.sh command to create/remove/list resources.
• control.sh command to register class path from server node resource.
  In strict environments it often prohibited for process to modify it's code (jars).
  So, regular flow with the "Ignite, please deploy files from the local disk to cluster" not working.
  We must provide a way to register and validate IgniteClassPath from server node local disks. 
• system view to list available instances.

Risks and Assumptions

// Describe project risks, such as API or binary compatibility issues, major protocol changes, etcWe assume that p2p and deployment SPI will be removed from Ignite.

Discussion Links

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

...