> 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? > > >>>>> > > >>>> > >
