Nikolay, we can (and probably should) discuss stop deploying caches/services to client nodes.
But I would not name it removal of client nodes at all. Any Apache Ignite guide I saw is starting from 2 steps: 1) start server node, 2) start client node. There are no reasons to write software if users are unaware of how to use it. So I do not agree that supplementary materials are unimportant. Sincerely, Dmitriy Pavlov пн, 17 июн. 2019 г. в 18:30, Nikolay Izhikov <nizhi...@apache.org>: > Dmitriy, > > I think the whole concept of "client" nodes is broken. > And that's why: > > Ignite Client node nothing to do with "client" :) > We can deploy cache on it, we can execute compute tasks, services on it. > "client node" is a node with special join process and some rebalance/PME > hacks. > And we put many(many!) efforts to support this concept and this hacks. > > And I'm asking: What value client nodes bring to Ignite? > > I think, Alexey, already answered correctly: > > * Transactions support. > * P2P deployment. > > I think we should, definitely, remove concept of "client nodes" in the > future. > It's about product design decision, in the first place, not about > additional materials. > > The simpler core codebase we have, the more reliable product we ca build > with it. > > > В Пн, 17/06/2019 в 18:19 +0300, Dmitriy Pavlov пишет: > > Hi Nikolay, > > > > I think client nodes removal is not possible in the near future because > of > > tons of usages everywhere outside Ignite code (in products, guides, > books, > > training, etc.) > > > > If we have replacement we should encourage users to migrate, but we can't > > remove such a core feature. > > > > Alexey, sure we can discuss removal of modules, why not? > > > > Sincerely, > > Dmitriy Pavlov > > > > пн, 17 июн. 2019 г. в 18:02, Alexey Zinoviev <zaleslaw....@gmail.com>: > > > > > Could we suggest here remove whole modules? > > > > > > пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk < > alexey.goncha...@gmail.com > > > > : > > > > Nikolay, > > > > > > > > I had this thought too, but I am not too eager to implement it yet. > The > > > > reason is transaction protocol complexity/performance issues with > thin > > > > clients. > > > > > > > > A thick client can communicate with each primary node and coordinate > > > > prepare/commit phases. Thin client can only communicate with one > node, so > > > > the change will mean an additional network hop. Of course, we can > make > > > > > > thin > > > > clients implement the same protocol, but it will immediately > increase the > > > > protocol complexity for all platforms. > > > > > > > > Plus, we do not have near cache on thin clients, we do not support > p2p > > > > class deployment, etc. Since thin clients are positioned as > > > > platform-agnostic, I do not think it makes sense to expose all > feature > > > > > > set > > > > of Igntie to thin clients. > > > > > > > > Instead, we can significantly simplify client node configuration - it > > > > currently requires the same config as a regular Ignite node, > however, in > > > > most cases, the configuration can be reduced almost to a several > > > > > > host:port > > > > pairs. > > > > > > > > пн, 17 июн. 2019 г. в 15:58, Nikolay Izhikov <nizhi...@apache.org>: > > > > > > > > > Alexey. > > > > > > > > > > I want to share a thought (just don't drop it out in one moment :) > ). > > > > > > > > > > Do we really need "client nodes"? > > > > > > > > > > We have thin client protocol that is a very convenient point to > > > > > > interact > > > > > with Ignite. > > > > > So, why, we need one more entity and work mode such as "client > node"? > > > > > > > > > > From my point of view, client nodes were required in the time > without a > > > > > thin client. > > > > > Now, we have it. > > > > > > > > > > Let's simplify Ignite codebase and drop client nodes! > > > > > > > > > > How does it sound? > > > > > > > > > > > > > > > В Пн, 17/06/2019 в 15:52 +0300, Alexey Goncharuk пишет: > > > > > > Nikolay, > > > > > > > > > > > > Local caches and scalar are already in the list :) Added the > outdated > > > > > > metrics point. > > > > > > > > > > > > пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov < > nizhi...@apache.org>: > > > > > > > > > > > > > * Scalar. > > > > > > > * LOCAL caches. > > > > > > > * Deprecated metrics. > > > > > > > > > > > > > > В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет: > > > > > > > > Igniters, > > > > > > > > > > > > > > > > Even though we are still planning the Ignite 2.8 release, I > would > > > > > > > > > > like to > > > > > > > > kick-off a discussion related to Ignite 3.0, because the > efforts > > > > > > > > for > > > > > AI > > > > > > > > > > > > > > 3.0 > > > > > > > > will be significantly larger than for AI 2.8, better to start > > > > > > > > early. > > > > > > > > > > > > > > > > As a first step, I would like to discuss the list of things > to be > > > > > > > > > > removed > > > > > > > > in Ignite 3.0 (partially this thread is inspired by Denis > Magda's > > > > > > > > > > IGFS > > > > > > > > removal thread). I've separated all to-be-removed points from > > > > > > > > > > existing > > > > > > > > Ignite 3.0 wishlist [1] to a dedicated block and also added > a few > > > > > > > > > > more > > > > > > > > things that look right to be dropped. > > > > > > > > > > > > > > > > Please share your thoughts, probably, there are more outdated > > > > > > > > things > > > > > we > > > > > > > > need to add to the wishlist. > > > > > > > > > > > > > > > > As a side question: I think it makes sense to create tickets > for > > > > > > > > such > > > > > > > > improvements, how do we track them. Will the 3.0 version > suffice > > > > > > or > > > > > > > > > > > > > > should > > > > > > > > we add a separate label? >
