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?
