Semi-anecdotal: I spoke to a lot of advanced Ignite users about the Ignite 3.x code deployment. The sentiment was from "that works" to "FINALLY!" - people aren't super-happy with DeploymentSpi and even with p2p in 2.x. They get the job done but you'll shoot yourself in the foot (aka failed prod) a dozen times before you figure out how to use it.
There is a deprecation mechanism in Ignite for a reason. You won't remove the features overnight but you can phase them out. p2p is the more popular of the two, but you can design a zero deployment experience based on IEP-103-style units - instead of the classes being read from a local file, you read them from a client (ignite-client://<client-name>/...). You can leave an extension point for custom artefact sources in the design, that'll do it. My 2 cents, Stan On Wed, Mar 11, 2026 at 11:53 AM Николай Ижиков <[email protected]> wrote: > Hello, Alex. > > > Any scenario with frequent code change (developing and testing, POC > creation). > > > Can you, please, be more specific? > Let’s describe and think how we must handle cases one by one. > > We can’t go forward with “any POC scenario”. > > > On 11 Mar 2026, at 18:41, Alex Plehanov <[email protected]> wrote: > > Can you, please, write down those scenarios? > > Any scenario with frequent code change (developing and testing, POC > creation). In these scenarios workflow can be as simple as: start > server nodes in Docker (or manually), start client nodes with your > code (even from IDE), and don't care about class deployment. Without > p2p classloading every iteration will require jars creation and > deployment to the server using tools. > > ср, 11 мар. 2026 г. в 10:23, Nikolay Izhikov <[email protected]>: > > > Hello, Alex. > > Thanks for your opinion. > > I think we shouldn't remove old implementations (p2p classloading and > deployment SPI). As far as I know these functionalities have users. > > > Common story for the API. > And yes, removing/redesign some public API WILL hurt some users. > > Removing any of these implementations will force users to change their > code. > > > Correct. > > From my point of view all deployment methods can coexist. > > > If they “can” doesn’t mean they “should” coexist. > I don’t think we ever want to keep three ways for deploying user > classes: IgniteClassPath, DeploymentSpi, peer class loading. > Even two are very bad from a product point of view. > > So we have make a choice: > > 1. Keep existing features for current users. > I estimate that the count of the users is relatively small. > > 2. Redesign it and hope for wider adoption. > > Please, keep in mind IgniteClassPath brings some of the key features > absent from DeploymentSpi and p2p deployment: > > 1. Ability to upgrade user code without any downtime. > 2. Ability to have several versions of user code in a cluster. > 3. Clear way to know which resources are available and how it get to > the cluster. > 4. Protection from random libs versions came from random client node. > 5. Ability to remove/unload resources from cluster. > > p2p classloading can be more convenient in some scenarios. > > > Can you, please, write down those scenarios? > > ср, 11 мар. 2026 г. в 10:21, Nikolay Izhikov <[email protected]>: > > > Hello, Alex. > > Thanks for your opinion. > > I think we shouldn't remove old implementations (p2p classloading and > deployment SPI). As far as I know these functionalities have users. > > > Common story for the API. > And yes, removing/redesign some public API WILL hurt some users. > > Removing any of these implementations will force users to change their > code. > > > Correct. > > From my point of view all deployment methods can coexist. > > > If they “can” doesn’t mean they “should” coexist. > I don’t think we ever want to keep three ways for deploying user classes: > IgniteClassPath, DeploymentSpi, peer class loading. > Even two are very bad from product point of view. > > So we have make a choice: > > 1. Keep existing feature for a current users. > I estimate that count of the users relatively small. > > 2. Redesign it and hope for wider adoption. > > Please, keep in mind IgniteClassPath brings some of the key features absent > from DeploymentSpi and p2p deployment: > > 1. Ability to upgrade user code without any downtime. > 2. Ability to have several versions of user code in cluster. > 3. Clear way to know which resources available and how the get to the > cluster. > 4. Protection from random libs versions came from random client node. > 5. Ability to remove/unload resources from cluster. > > p2p classloading can be more convenient in some scenarios. > > > Can you, please, write down those scenarios? > > > On 10 Mar 2026, at 23:14, Alex Plehanov <[email protected]> wrote: > > Regarding the phrase: "We assume that p2p and deployment SPI will be > removed from Ignite" > > I think we shouldn't remove old implementations (p2p classloading and > deployment SPI). As far as I know these functionalities have users. > Removing any of these implementations will force users to change their > code. From my point of view all deployment methods can coexist. > Also, I think P2P classloading is a very useful feature for > quick-starting. The new deployment functionality requires additional > steps from users, p2p classloading can be more convenient in some > scenarios. > > пн, 2 мар. 2026 г. в 22:57, Alex Plehanov <[email protected]>: > > > +1 for something containing "deployment": > 1. Naming consistency with "Deployment SPI". Even if it will be > removed later, it solves the same problem. > 2. Naming consistency with Ignite 3. > 3. IgniteClassPath sounds like some system-property, where we can set > some path, but not something that we can upload to the server. > > чт, 26 февр. 2026 г. в 14:47, Maksim Timonin <[email protected]>: > > > Hi, > > I suppose that being *java-centric* is one of the core features of Ignite > (at least for 2.x), so terms should be self-explanatory for java > developers. IgniteClassPath is a good term, whereas DeploymentUnit feels > too general. The term "deployment" is somewhat misleading here because it > carries a specific, different meaning in Kubernetes (and looks like MongoDB > uses it in the same way). > > I also find possible CLI syntax very intuitive for developers: > ./control.sh [compute|service...] --run MyTask --class-path id. (or even > -cp) > > Also, Spark and Flink use explicit cli options for non-java resources (for > example, --py-files, --pyFiles). I think we can implement similar explicit > APIs for other languages in the future, if required. > > > On Wed, Feb 25, 2026 at 4:30 PM Anton Vinogradov <[email protected]> wrote: > > +1 to ClassPath since in because of java > > On Wed, Feb 25, 2026 at 12:12 PM Nikolay Izhikov <[email protected]> > wrote: > > Hello. > > If you look at the Apache Spark and Flink examples, we can specify > > where > > the jars will be taken from(local, hdfs, http, https, ftp). Will this > functionality be supported? > > Yes, but via extensions. > > If so, perhaps it would be useful to create a whitelist of resources > > from which resources can be loaded? > > Useful insight. Will add it in IEP. > > ср, 25 февр. 2026 г. в 11:35, ткаленко кирилл <[email protected]>: > > > Hi. > > I agree with colleagues about the "Deployment Unit" term. > The IEP provides example commands specifying additional jars, but you > > have an idea to add both jars and other resources. I think it would be > > very > > useful to add other libraries for the languages we support this way. > > > If you look at the Apache Spark and Flink examples, we can specify > > where > > the jars will be taken from(local, hdfs, http, https, ftp). Will this > functionality be supported? > > If so, perhaps it would be useful to create a whitelist of resources > > from which resources can be loaded? > > > Will there be separate permissions for the add/remove resource > > commands? >
