Folks, Should we perform cleanup work before (r)evolutional changes? My huge proposal is to get rid of things which we don't need anyway - local caches, - strange tx modes, - code overcomplexity because of RollingUpgrade feature never attended at AI, - etc, before choosing the way.
On Tue, Nov 3, 2020 at 3:31 PM Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Ksenia, thanks for scheduling this on such short notice! > > As for the original topic, I do support Alexey's idea. We're not going to > rewrite anything from scratch, as most of the components are going to be > moved as-is or with minimal modifications. However, the changes that are > proposed imply serious rework of the core parts of the code, which are not > properly decoupled from each other and from other parts. This makes the > incremental approach borderline impossible. Developing in a new repo, > however, addresses this concern. As a bonus, we can also refactor the code, > introduce better decoupling, get rid of kernel context, and develop unit > tests (finally!). > > Basically, this proposal only affects the *process*, not the set of changes > we had discussed before. Ignite 3.0 is our unique chance to make things > right. > > -Val > > On Tue, Nov 3, 2020 at 3:06 AM Kseniya Romanova <romanova.ks....@gmail.com > > > wrote: > > > Pavel, all the interesting points will be anyway published here in > English > > (as the principal "if it's not on devlist it doesn't happened" is still > > relevant). This is just a quick call for a group of developers. Later we > > can do a separate presentation of idea and discussion in English as we > did > > for the Ignite 3.0 draft of changes. > > > > вт, 3 нояб. 2020 г. в 13:52, Pavel Tupitsyn <ptupit...@apache.org>: > > > > > Kseniya, > > > > > > Thanks for scheduling this call. > > > Do you think we can switch to English if non-Russian speaking community > > > members decide to join? > > > > > > On Tue, Nov 3, 2020 at 1:32 PM Kseniya Romanova < > > romanova.ks....@gmail.com > > > > > > > wrote: > > > > > > > Let's do this community discussion open. Here's the link on zoom call > > in > > > > Russian for Friday 6 PM: > > > > https://www.meetup.com/Moscow-Apache-Ignite-Meetup/events/274360378/ > > > > > > > > вт, 3 нояб. 2020 г. в 12:49, Nikolay Izhikov <nizhi...@apache.org>: > > > > > > > > > Time works for me. > > > > > > > > > > > 3 нояб. 2020 г., в 12:40, Alexey Goncharuk < > > > alexey.goncha...@gmail.com > > > > > > > > > > написал(а): > > > > > > > > > > > > Nikolay, > > > > > > > > > > > > I am up for the call. I will try to explain my reasoning in > greater > > > > > detail > > > > > > and will be glad to hear the concerns. Will this Friday, Nov 6th, > > > work? > > > > > > > > > > > > вт, 3 нояб. 2020 г. в 10:09, Nikolay Izhikov < > nizhi...@apache.org > > >: > > > > > > > > > > > >> Igniters, should we have a call for this topic? > > > > > >> > > > > > >>> 2 нояб. 2020 г., в 18:53, Pavel Tupitsyn <ptupit...@apache.org > > > > > > > >> написал(а): > > > > > >>> > > > > > >>>> not intend to rewrite everything from scratch > > > > > >>> > > > > > >>>> Every single test from Ignite 2.x should be moved to Ignite 3 > > > > > >>>> regardless of how we choose to proceed. > > > > > >>> > > > > > >>> Alexey, thank you for the explanation, this addresses all of my > > > > > concerns. > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> On Mon, Nov 2, 2020 at 6:43 PM Andrey Mashenkov < > > > > > >> andrey.mashen...@gmail.com> > > > > > >>> wrote: > > > > > >>> > > > > > >>>> Hi, Igniters. > > > > > >>>> > > > > > >>>> * AFAIU, we need a new repo if we want to apply different > > > > restrictions > > > > > >> to > > > > > >>>> pull requests, > > > > > >>>> otherwise I see no difference for myself. > > > > > >>>> E.g. make static analysis (do we have?), compile, styles, and > > > > javadoc > > > > > >>>> checks mandatory. > > > > > >>>> > > > > > >>>> I think that relaxed requirements here will lead to bad > product > > > > > quality. > > > > > >>>> > > > > > >>>> * Agree with Pavel, we should 'keep' integrations tests > somehow. > > > > > >>>> During active development tests will be broken most of time, > so, > > > > > >>>> I'd port them e.g. suite-by-suite once we will have a stable > and > > > > > >> featured > > > > > >>>> environment to run them and of course make test's code clear > and > > > > avoid > > > > > >>>> bad/non-relevant ones. > > > > > >>>> > > > > > >>>> * I like bottom-up approach. > > > > > >>>> With it we could make a better framework. I mean clear > component > > > > > >> lifecycle, > > > > > >>>> component wiring mechanics, general methods to approach core > > > > > components > > > > > >>>> such as exchange/communication > > > > > >>>> to avoid code mess like we have in ExchangeFuture with all > these > > > > > custom > > > > > >>>> callbacks for each component, interfaces like > > > > > >>>> PartitionsExchangeAware, IgniteChangeGlobalStateSupport and > > > > > >>>> a pack of > > > > > >> start/stop/onKernalStart/onPluginStart/onActivate/onDisconnected > > > > > >>>> and so on in various unexpected places. > > > > > >>>> Hope, we will be able to port most of the good code to the new > > > > > framework > > > > > >>>> version. > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> On Mon, Nov 2, 2020 at 6:18 PM Alexey Goncharuk < > > > > > >>>> alexey.goncha...@gmail.com> > > > > > >>>> wrote: > > > > > >>>> > > > > > >>>>> Nikolay, Pavel, > > > > > >>>>> > > > > > >>>>> Thanks for the feedback! First of all, I wanted to stress > that > > I > > > do > > > > > not > > > > > >>>>> intend to rewrite everything from scratch (I never used this > > > > phrase). > > > > > >>>> There > > > > > >>>>> are significant parts of code that would be moved with > minimal > > > > > >>>>> modifications. Second, I never said that we will get rid of > the > > > old > > > > > >> tests > > > > > >>>>> codebase. Every single test from Ignite 2.x should be moved > to > > > > > Ignite 3 > > > > > >>>>> regardless of how we choose to proceed. > > > > > >>>>> > > > > > >>>>> My point is that for some parts of the code a clean bottom-up > > > > > >>>>> implementation will be cheaper in many ways. Let me give you > a > > > few > > > > > >>>> concrete > > > > > >>>>> examples: > > > > > >>>>> > > > > > >>>>> - I think no one can object that we need a cleanly separated > > > > > >>>> persistence > > > > > >>>>> layer for Ignite. There is a very raw draft IEP for this > > > already. > > > > On > > > > > >>>> the > > > > > >>>>> other hand, I think we also can agree that we need a > > split-brain > > > > > >>>>> resistant > > > > > >>>>> replication protocol for caches. There is also an IEP for > > this. > > > > > >>>> Neither > > > > > >>>>> of > > > > > >>>>> the changes is a good fit for 2.x because they are likely to > > > > > >> introduce > > > > > >>>>> breaking changes in the persistence layer, configuration and > > > > > >> behavior. > > > > > >>>>> Additionally, these components are now tightly coupled, so > > there > > > > is > > > > > >> no > > > > > >>>>> way > > > > > >>>>> these two changes can be implemented in parallel and then > > merged > > > > > >>>>> together > > > > > >>>>> easily. So what we will end up with is having to implement > > these > > > > > >>>> changes > > > > > >>>>> sequentially, fixing all existing tests twice, and > essentially > > > > > >>>> throwing > > > > > >>>>> away half of the work done because the other part of the > > change > > > is > > > > > >>>>> re-implemented > > > > > >>>>> - Similar example goes with getting rid of > > IgniteInternalFuture > > > > and > > > > > >>>>> replacing it with CompletableFuture, and any other change > that > > > > > >> touches > > > > > >>>>> the > > > > > >>>>> asynchronous part of the code. > > > > > >>>>> > > > > > >>>>> Third, I do not see how this choice affects the UX of Ignite. > > The > > > > end > > > > > >>>> user > > > > > >>>>> experience must be fixed in the IEP regardless of the > > development > > > > > >> process > > > > > >>>>> and the fact that we have gaps in this area in Ignite 2.x > just > > > > > confirms > > > > > >>>>> that. > > > > > >>>>> > > > > > >>>>> Pavel, agree that a repo/branch is a technicality, I guess if > > > > > >>>> reformulate, > > > > > >>>>> my point is that we might agree to have a single development > > > master > > > > > >>>> branch > > > > > >>>>> with 'disassembled' end-to-end functionality for some period > of > > > > time > > > > > to > > > > > >>>>> speed up development, and re-assemble the core features after > > > > having > > > > > >>>>> submodules tested independently. > > > > > >>>>> > > > > > >>>>> Nikolay, > > > > > >>>>>> We have many features that have to evolve. > > > > > >>>>>> Snapshots, rebalance, tooling, tracing, zookeeper support, > > etc. > > > > > >>>>> This is not very specific. In the end, resources are limited > > and > > > we > > > > > >> will > > > > > >>>>> not be able to drive both tracks simultaneously, especially > > > after a > > > > > >>>> couple > > > > > >>>>> of features having been implemented for Ignite 3.0. If there > > are > > > > > indeed > > > > > >>>>> some major changes that we want to do in Ignite 2.x instead > of > > > > > putting > > > > > >>>>> effort into 3.0 - let's discuss them. I am just not aware of > > any, > > > > > >> that's > > > > > >>>>> why I am eager to move forward with Ignite 3.0. > > > > > >>>>> > > > > > >>>>>> We have bugs and issues that can be fixed in 2.x without > > > breaking > > > > > >>>> backward > > > > > >>>>> compatibility. > > > > > >>>>>> We have many users who are happy with the 2.x with all it’s > > > > issues. > > > > > >>>>> These changes will be covered by end-to-end tests and > migrated > > to > > > > > >> Ignite > > > > > >>>>> 3.0, so I see no issues here. > > > > > >>>>> > > > > > >>>>> Finally, Anton & Nikolay > > > > > >>>>> I do not have an estimate for this simply because the > activity > > is > > > > > >>>>> community-driven and it depends on the number of people > willing > > > to > > > > > >>>>> contribute. With the current pace, I would hope to have an RC > > of > > > > > Ignite > > > > > >>>> 3.0 > > > > > >>>>> to be ready by the end of 2021. My gut feeling is that by > > moving > > > > with > > > > > >>>>> incremental changes, we will not be able to implement even > half > > > of > > > > > the > > > > > >>>>> wishlist by that time. > > > > > >>>>> I doubt that releasing several major releases with breaking > > > changes > > > > > >> will > > > > > >>>>> make Ignite users happy either because each upgrade will cost > > > > Ignite > > > > > >>>> users > > > > > >>>>> money, so the fewer major versions we release, the better. > Thus > > > my > > > > > wish > > > > > >>>> to > > > > > >>>>> include all breaking changes in one release. > > > > > >>>>> > > > > > >>>>> I'll be now quiet for a while, let's see what other community > > > > members > > > > > >>>>> think. > > > > > >>>>> > > > > > >>>>> пн, 2 нояб. 2020 г. в 15:52, Pavel Tupitsyn < > > > ptupit...@apache.org > > > > >: > > > > > >>>>> > > > > > >>>>>> 1. Rewriting from scratch is never a good idea. > > > > > >>>>>> We don't want to follow the path of Netscape and lose all > our > > > > users > > > > > >>>>>> by the time we have a working 3.0 [1] > > > > > >>>>>> > > > > > >>>>>> 2. Not sure about new repo - seems like some pain and no > gain, > > > > > what's > > > > > >>>> the > > > > > >>>>>> problem with a branch? > > > > > >>>>>> > > > > > >>>>>> 3. We should keep existing integration tests when possible. > > > > > >>>>>> We have accumulated a lot of edge case knowledge over the > > years, > > > > > >>>>>> it is not a good idea to send all of that down the drain. > > > > > >>>>>> Yes, integration tests are slow, but they are the most > > valuable. > > > > > >>>>>> I think we can move more stuff into nightly runs and have a > > fast > > > > and > > > > > >>>>> modern > > > > > >>>>>> basic suite. > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> Alexey, you are much more familiar with the Ignite core > > codebase > > > > > than > > > > > >>>>> most > > > > > >>>>>> of us, > > > > > >>>>>> can you please explain in more detail which particular > > feature, > > > in > > > > > >> your > > > > > >>>>>> opinion, > > > > > >>>>>> mandates this "start from scratch" approach? > > > > > >>>>>> Is it really not possible at all to follow a less radical > way? > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> [1] > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>> > > > > > >>>> > > > > > >> > > > > > > > > > > > > > > > https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ > > > > > >>>>>> > > > > > >>>>>> On Mon, Nov 2, 2020 at 2:25 PM Nikolay Izhikov < > > > > nizhi...@apache.org > > > > > > > > > > > >>>>>> wrote: > > > > > >>>>>> > > > > > >>>>>>> Hello, Alexey. > > > > > >>>>>>> > > > > > >>>>>>> I think that «rewriting from scratch» approach has a high > > risk > > > to > > > > > >>>> make > > > > > >>>>>> new > > > > > >>>>>>> features unusable. > > > > > >>>>>>> At the time Ignite2 was started no-one wants to do bad UX > or > > > bad > > > > > >>>>>> features. > > > > > >>>>>>> Nevertheless, it happen. > > > > > >>>>>>> > > > > > >>>>>>> I think we can avoid it with the Ignite3 and successors if > we > > > > will > > > > > >>>> move > > > > > >>>>>>> step by step without keeping backward compatibility > > > > > >>>>>>> With the step by step approach, we can focus on each > > component > > > > > >>>>>> separately. > > > > > >>>>>>> > > > > > >>>>>>>> What new features are we planning to implement for Ignite > > 2.x? > > > > > >>>>>>> > > > > > >>>>>>> We have many features that have to evolve. > > > > > >>>>>>> Snapshots, rebalance, tooling, tracing, zookeeper support, > > etc. > > > > > >>>>>>> We have bugs and issues that can be fixed in 2.x without > > > breaking > > > > > >>>>>> backward > > > > > >>>>>>> compatibility. > > > > > >>>>>>> We have many users who are happy with the 2.x with all it’s > > > > issues. > > > > > >>>>>>> > > > > > >>>>>>>> 2 нояб. 2020 г., в 14:09, Anton Vinogradov <a...@apache.org > > > > > > > >>>>> написал(а): > > > > > >>>>>>>> > > > > > >>>>>>>> Alexey, > > > > > >>>>>>>> > > > > > >>>>>>>> Do we have any estimates of how fast we'll be able to gain > > > > > >>>>>>> production-ready > > > > > >>>>>>>> AI 3.0 in case of a "new repo" choice? > > > > > >>>>>>>> > > > > > >>>>>>>> On Mon, Nov 2, 2020 at 2:01 PM Alexey Goncharuk < > > > > > >>>>>>> alexey.goncha...@gmail.com> > > > > > >>>>>>>> wrote: > > > > > >>>>>>>> > > > > > >>>>>>>>> Nikolay, > > > > > >>>>>>>>> > > > > > >>>>>>>>> What new features are we planning to implement for Ignite > > > 2.x? > > > > I > > > > > >>>>> think > > > > > >>>>>>> once > > > > > >>>>>>>>> we commence working on Ignite 3.0, we should gradually > > cease > > > > the > > > > > >>>>>>> activity > > > > > >>>>>>>>> on Ignite 2.x to mere bugfixes because such parallel > > > > development > > > > > >>>>> will > > > > > >>>>>> be > > > > > >>>>>>>>> overwhelming regardless of how we choose to proceed. > > > > > >>>>>>>>> > > > > > >>>>>>>>> пн, 2 нояб. 2020 г. в 13:38, Nikolay Izhikov < > > > > > nizhi...@apache.org > > > > > >>>>> : > > > > > >>>>>>>>> > > > > > >>>>>>>>>> To be clear: > > > > > >>>>>>>>>> > > > > > >>>>>>>>>>> I would suggest creating a new repository for Ignite > 3.0 > > > > > >>>>> (perhaps, a > > > > > >>>>>>>>> new > > > > > >>>>>>>>>> clean branch, but a new repo looks nicer to me) and a > new > > > > Ignite > > > > > >>>>> 3.0 > > > > > >>>>>>>>>> TeamCity project. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> +1 for new Team City project. > > > > > >>>>>>>>>> +1 for new branch for Ignite3. > > > > > >>>>>>>>>> -1 for new repo. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>>> 2 нояб. 2020 г., в 13:35, Nikolay Izhikov < > > > > > >>>> nizhikov....@gmail.com > > > > > >>>>>> > > > > > >>>>>>>>>> написал(а): > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> Hello, Alexey. > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> I think it will hurt our project more than help. > > > > > >>>>>>>>>>> Developing new features for 2 separate branches with > the > > > > > >>>> different > > > > > >>>>>>> APIs > > > > > >>>>>>>>>> and internal structure is overwhelming > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>> Maybe we should relax a bit requirements for Ignite3? > > > > > >>>>>>>>>>> Maybe we should move step by step and make Ignite3 with > > new > > > > > >>>>>>>>>> configuration than Ignite4 with new transactions, etc? > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>>>> 2 нояб. 2020 г., в 13:14, Alexey Goncharuk < > > > > > >>>>>>>>> alexey.goncha...@gmail.com> > > > > > >>>>>>>>>> написал(а): > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> Igniters, > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> I wanted to pitch a rather radical idea regarding the > > > Ignite > > > > > >>>> 3.0 > > > > > >>>>>>>>>>>> development which has occurred to me some time ago. > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> We already have several IEPs targeted to Ignite 3.0 > > which > > > > > imply > > > > > >>>>>> major > > > > > >>>>>>>>>>>> changes to the codebase (the change in replication > > > protocol > > > > > and > > > > > >>>>>> thus > > > > > >>>>>>>>>>>> transactions, change in binary format, updated > > > metastorage, > > > > > >>>> etc). > > > > > >>>>>> We > > > > > >>>>>>>>>> also > > > > > >>>>>>>>>>>> planned significant changes in public APIs: > > configuration > > > > > >>>> format > > > > > >>>>>>>>> change, > > > > > >>>>>>>>>>>> improvements in cache APIs, SQL APIs, transaction mode > > > > rework. > > > > > >>>>> The > > > > > >>>>>>>>>> wishlist > > > > > >>>>>>>>>>>> of changes for Ignite 3.0 is huge. > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> So, I was wondering whether it makes sense to try to > > > change > > > > > the > > > > > >>>>> old > > > > > >>>>>>>>>>>> codebase, or start with a new baseline and move old > > pieces > > > > of > > > > > >>>>> code > > > > > >>>>>>>>> that > > > > > >>>>>>>>>> do > > > > > >>>>>>>>>>>> not require significant rework. Personally, I would go > > > with > > > > > the > > > > > >>>>>>> second > > > > > >>>>>>>>>>>> option for the following reasons: > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> - We have a chance to shift the development paradigm > in > > > the > > > > > >>>>> project > > > > > >>>>>>>>> and > > > > > >>>>>>>>>>>> introduce the practice of true unit-tests. In the new > > > > baseline > > > > > >>>> at > > > > > >>>>>> the > > > > > >>>>>>>>>>>> beginning there will be no ability to run an > end-to-end > > > > > >>>> scenario, > > > > > >>>>>>>>> thus > > > > > >>>>>>>>>> we > > > > > >>>>>>>>>>>> will be forced to write unit-tests. So far, such > > practice > > > > was > > > > > >>>>> hard > > > > > >>>>>> to > > > > > >>>>>>>>>>>> implement because of tight coupling between Ignite > > > > components > > > > > >>>> and > > > > > >>>>>>>>>> inability > > > > > >>>>>>>>>>>> to instantiate components without an instance of > > > > > KernalContext. > > > > > >>>>> For > > > > > >>>>>>>>>>>> example, we should be able to thoroughly test internal > > > > > >>>>> primitives, > > > > > >>>>>>>>>> such as > > > > > >>>>>>>>>>>> replication protocol (without actual communication), > > > > > >>>> distributed > > > > > >>>>>>>>>>>> metastorage contracts, persistence layer, etc. > > > > > >>>>>>>>>>>> - We will significantly reduce the development cycle > in > > > the > > > > > >>>>>> beginning > > > > > >>>>>>>>>>>> (right now the RunAll takes two hours of astronomical > > time > > > > > with > > > > > >>>>>> empty > > > > > >>>>>>>>>> TC; > > > > > >>>>>>>>>>>> in the new approach developer will be able to run ALL > > > tests > > > > > >>>>> locally > > > > > >>>>>>>>> in > > > > > >>>>>>>>>> a > > > > > >>>>>>>>>>>> matter of minutes) > > > > > >>>>>>>>>>>> - We can get rid of TC bot and enforce green TC by > > > > integrating > > > > > >>>> TC > > > > > >>>>>>>>> build > > > > > >>>>>>>>>>>> results with GitHub PRs (the same way Travis is > > currently > > > > > >>>>>> integrated > > > > > >>>>>>>>>> to PR > > > > > >>>>>>>>>>>> check). We should restrict PR merge without a TC check > > > > > >>>>>>>>>>>> - We will still have to re-write all tests, but only > > once. > > > > If > > > > > >>>> we > > > > > >>>>>> try > > > > > >>>>>>>>> to > > > > > >>>>>>>>>>>> modify the old codebase, we would need to modify all > the > > > > tests > > > > > >>>>> for > > > > > >>>>>>>>>> every > > > > > >>>>>>>>>>>> major change (public API change, configuration change) > > > > > >>>>>>>>>>>> - We will have fewer conflicts when working together. > > For > > > > > >>>>> example, > > > > > >>>>>> I > > > > > >>>>>>>>>>>> cannot imagine how one would merge two changes of > > getting > > > > rid > > > > > >>>> of > > > > > >>>>>>>>>>>> IgniteFuture and changes in replication protocol, for > > > > example > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> Technically, I would suggest creating a new repository > > for > > > > > >>>> Ignite > > > > > >>>>>> 3.0 > > > > > >>>>>>>>>>>> (perhaps, a new clean branch, but a new repo looks > nicer > > > to > > > > > me) > > > > > >>>>>> and a > > > > > >>>>>>>>>> new > > > > > >>>>>>>>>>>> Ignite 3.0 TeamCity project. > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> While it may seem quite radical, I do believe that > this > > > > > >>>> approach > > > > > >>>>>> will > > > > > >>>>>>>>>> give > > > > > >>>>>>>>>>>> us more benefits than trying to make such major > changes > > in > > > > the > > > > > >>>>>>>>> existing > > > > > >>>>>>>>>>>> codebase. If needed, let's schedule a discord chat > like > > > > before > > > > > >>>> to > > > > > >>>>>>>>>> discuss > > > > > >>>>>>>>>>>> this. > > > > > >>>>>>>>>>>> > > > > > >>>>>>>>>>>> WDYT? > > > > > >>>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> > > > > > >>>>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>> > > > > > >>>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> -- > > > > > >>>> Best regards, > > > > > >>>> Andrey V. Mashenkov > > > > > >>>> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > >
