We found an issue, we never set up group access before: now committers (wiki group: ignite) can edit and create pages, and PMC members (wiki group: ignite-pmc) are admins.
Andrey, could you confirm you can edit now? вт, 18 июн. 2019 г. в 13:33, Dmitriy Pavlov <dpav...@apache.org>: > Hi Ivan, thank you for this bit of information. We seem to be on the same > page about a removal, and it would not happen in 3.0. My concern related to > public API and users. If we internally redesign thick clients and remove > counter-intuitive use cases (e.g. caches on a client, excepting near > caches) it is perfectly fine, and I encourage everyone to propose solutions > in this issue. > > Hi Andrey, please check your Apache ID while login to wiki. Since you are > comitter you should be able to edit (INFRA set up LDAP recently). > > If it will not work, please share your wiki username, and I will add > permissions. > > Sincerely > Dmitriy Pavlov > > вт, 18 июн. 2019 г. в 12:32, Павлухин Иван <vololo...@gmail.com>: > >> Nikolay, Dmitriy, >> >> Should we have a separate thread devoted to client nodes? >> >> Also, my cent here is from a Hazelcast history. Once they removed >> their thick client (called LiteMember), but after a while they brought >> it back. I think we need to learn this lesson in more details. >> >> вт, 18 июн. 2019 г. в 11:42, Andrey Mashenkov <andrey.mashen...@gmail.com >> >: >> > >> > Also, >> > * Get rid of old services. >> > * Make system cache non-persistent or even more - drop it. Discussion on >> > dev list [1]. >> > >> > I have no permissions to edit wiki page and would glad if someone add >> all >> > thoughts from this thread. >> > >> > [1] >> > >> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-System-cache-persistence-td41158.html >> > >> > On Tue, Jun 18, 2019 at 10:33 AM Alexey Goncharuk < >> > alexey.goncha...@gmail.com> wrote: >> > >> > > Folks, >> > > >> > > May I ask you to add the mentioned points to the wishlist to keep >> them in >> > > one place for convenience? >> > > >> > > вт, 18 июн. 2019 г. в 00:19, Alex Plehanov <plehanov.a...@gmail.com>: >> > > >> > > > Remove "force server mode" for client nodes (already was discussed >> on dev >> > > > list earlier [1]). >> > > > >> > > > [1] : >> > > > >> > > > >> > > >> http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-server-mode-for-clients-td33614.html >> > > > >> > > > пн, 17 июн. 2019 г. в 19:22, Pavel Tupitsyn <ptupit...@apache.org>: >> > > > >> > > > > Big changes for .NET: >> > > > > * Remove legacy Entity Framework integration >> > > > > * Remove legacy ASP.NET integration >> > > > > * Move from .NET Framework 4.0 (released in 2010) to .NET >> Standard 2.0 >> > > > > (modern way to build libraries) >> > > > > >> > > > > Thanks, >> > > > > Pavel >> > > > > >> > > > > On Mon, Jun 17, 2019 at 7:14 PM Igor Sapego <isap...@gridgain.com >> > >> > > > wrote: >> > > > > >> > > > > > For the C++ I propose to drop support of VS 2010 and move to >> > > > > > at least 2012 (or, better yet 2013). >> > > > > > >> > > > > > Also, I'd drop x86 support for everything except for maybe ODBC. >> > > > > > >> > > > > > Best Regards, >> > > > > > Igor >> > > > > > >> > > > > > On Mon, Jun 17, 2019 at 7:12 PM Pavel Kovalenko < >> jokse...@gmail.com> >> > > > > > wrote: >> > > > > > >> > > > > > > I would like to add to the list following: >> > > > > > > >> > > > > > > 1. Remove ForceKeyRequests and related code. Since we have >> Late >> > > > > affinity >> > > > > > > assignment and primary node partitions are always up to date >> we >> > > don't >> > > > > > need >> > > > > > > to request actual data from backups. >> > > > > > > 2. Remove @CentralizedAffinityFunction and related code. I >> don't >> > > see >> > > > > any >> > > > > > > real usages of custom affinity functions that use this >> annotation. >> > > > > > > 3. Leave Exchanges Merge + Late Affinity assignment as the >> only PME >> > > > > > > protocol. Remove centralized affinity distribution in case of >> node >> > > > left >> > > > > > and >> > > > > > > no merge exchange legacy modes. >> > > > > > > 4. Remove CacheRebalanceMode.NONE and Rebalance Delay as it >> can >> > > break >> > > > > > data >> > > > > > > consistency in a cluster. Also, remove force rebalance mode >> as it >> > > can >> > > > > be >> > > > > > > used only if rebalance delay is set. >> > > > > > > >> > > > > > > пн, 17 июн. 2019 г. в 18:39, Dmitriy Pavlov < >> dpav...@apache.org>: >> > > > > > > >> > > > > > > > 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? >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> > >> > -- >> > Best regards, >> > Andrey V. Mashenkov >> >> >> >> -- >> Best regards, >> Ivan Pavlukhin >> >
