Dmitriy. When we remove all "features" that is uncommon for the term "client node" what will remain? Thin client protocol with transactions and P2P feature.
I'm talking about design and naming, not about "documentation and supplementary materials". We should have clear and consistent design and then explain it to users. > 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. I don't say they are unimportant. I'm saying that we lie to our users with naming in the configuration. For now, "client node" is not client from any point of view. В Пн, 17/06/2019 в 18:38 +0300, Dmitriy Pavlov пишет: > 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?
signature.asc
Description: This is a digitally signed message part
