Hello! I have just merged slim binary release to master.
I will now try to tweak nightly builds TC suite to build this package also. It may be broken for some brief period of time. Regards, -- Ilya Kasnacheev вт, 10 мар. 2020 г. в 18:24, Ilya Kasnacheev <ilya.kasnach...@gmail.com>: > Hello! > > I understand that procedures are courtesy Apache Ignite, but I assume that > you went through them and can now repeat them reproducibly. > > Thank you! > -- > Ilya Kasnacheev > > > вт, 10 мар. 2020 г. в 18:12, Maxim Muzafarov <mmu...@apache.org>: > >> Ilya, >> >> It is not "mine" generic release procedures they are "ours" :-) >> I've created the issue [1] based on current discussion thread. >> >> >> [1] https://issues.apache.org/jira/browse/IGNITE-12765 >> >> On Tue, 10 Mar 2020 at 13:31, Ilya Kasnacheev <ilya.kasnach...@gmail.com> >> wrote: >> > >> > Hello! >> > >> > It is currently included. >> > >> > Maxim, can you prepare a slim release package based on your generic >> release >> > procedures? We could take a look at it and then perhaps add it to >> downloads >> > page officially. >> > >> > What do you think? >> > >> > Regards, >> > -- >> > Ilya Kasnacheev >> > >> > >> > пт, 6 мар. 2020 г. в 20:48, Maxim Muzafarov <mmu...@apache.org>: >> > >> > > Ilya, >> > > >> > > `ignite-compress` is necessary for `wal page snapshot compression` [1] >> > > which in turn shows very good performance results. So, I suppose, it's >> > > better to include it to the "slim" binary. >> > > >> > > [1] https://issues.apache.org/jira/browse/IGNITE-11336 >> > > >> > > On Fri, 6 Mar 2020 at 13:31, Ilya Kasnacheev < >> ilya.kasnach...@gmail.com> >> > > wrote: >> > > > >> > > > Hello! >> > > > >> > > > I added these because they are infrastructural to Ignite, as >> opposed to >> > > > integrations. They are also both very slim. >> > > > >> > > > Regards, >> > > > -- >> > > > Ilya Kasnacheev >> > > > >> > > > >> > > > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington < >> > > > stephen.darling...@gridgain.com>: >> > > > >> > > > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I know >> very >> > > few >> > > > > people who use either. >> > > > > >> > > > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev < >> ilya.kasnach...@gmail.com> >> > > > > wrote: >> > > > > > >> > > > > > Hello! >> > > > > > >> > > > > > Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1* >> > > > > > >> > > > > > I have prepared assemblies for Apache Ignite slim packaging: >> > > > > > https://github.com/apache/ignite/tree/ignite-slim >> > > > > > >> > > > > > It is based on ignite-2.8 >> > > > > > >> > > > > > You can build it with mvn initialize -Prelease,lgpl >> > > > > -Dignite.edition=apache- >> > > > > > ignite-slim after a normal release build. >> > > > > > >> > > > > > Please consider the contents of resulting >> > > > > > target/bin/apache-ignite-slim-2.8.0-bin.zip >> > > > > > It will be a 65M download as opposed to main 455M >> apache-ignite-2.8.0 >> > > > > > distribution. >> > > > > > >> > > > > > My suggestion is that we can publish it as a post-release step >> since >> > > it >> > > > > > does not affect the release in any way. If we do, we should >> probably >> > > > > > indicate size for every kind of artifact in our download >> section, so >> > > our >> > > > > > users can choose based on that information. >> > > > > > >> > > > > > The following modules are included: >> > > > > > >> > > > > > libs: >> > > > > > core/shmem/jcache >> > > > > > ignite-indexing >> > > > > > ignite-spring >> > > > > > >> > > > > > libs/optional: >> > > > > > ignite-compress ignite-kubernetes ignite-log4j2 >> > > ignite-rest-http >> > > > > > ignite-spring-data_2.2 >> > > > > > ignite-jta ignite-log4j ignite-opencensus >> ignite-slf4j >> > > > > > ignite-urideploy >> > > > > > >> > > > > > I have kept examples, but removed benchmarks. sqlline still >> present, >> > > of >> > > > > > course. >> > > > > > >> > > > > > ignite-zookeeper has a lot of dependencies (8M) which we do not >> > > update >> > > > > > often enough (such as guava, curator, jackson), and which may >> form an >> > > > > > attack surface. >> > > > > > >> > > > > > Not a pressing problem for 'integrated' ignite-zookeeper users, >> since >> > > > > they >> > > > > > can re-import these dependencies with more recent versions using >> > > maven or >> > > > > > gradle. >> > > > > > But for our users who rely on binary package for all JARs, >> outdated >> > > > > > dependencies may pose a problem. >> > > > > > >> > > > > > Therefore my opinion is to exclude this dependency and not put >> our >> > > faith >> > > > > on >> > > > > > zookeeper dependency version. >> > > > > > >> > > > > > The same can be put for ignite-compress, and indeed, I'm not >> sure if >> > > we >> > > > > > should keep it. >> > > > > > >> > > > > > We can have an ad-hoc vote here. >> > > > > > >> > > > > > I would like to hear arguments for both inclusion and exclusion >> of >> > > > > > ignite-zookeeper and ignite-compress into slim package (in any >> > > > > combination). >> > > > > > >> > > > > > I would also like to know if you want a formal vote on the >> issue. >> > > > > > >> > > > > > Regards, >> > > > > > -- >> > > > > > Ilya Kasnacheev >> > > > > > >> > > > > > >> > > > > > пн, 27 янв. 2020 г. в 21:13, Denis Magda <dma...@apache.org>: >> > > > > > >> > > > > >> Alex, could you please list all the modules that will be >> excluded? >> > > It >> > > > > will >> > > > > >> help to confirm we haven't dumped anything essential. >> > > > > >> >> > > > > >> - >> > > > > >> Denis >> > > > > >> >> > > > > >> >> > > > > >> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk < >> > > > > >> alexey.goncha...@gmail.com> wrote: >> > > > > >> >> > > > > >>> Got it, sounds good! >> > > > > >>> Should we consider the list of modules included in the slim >> package >> > > > > >>> finalized? >> > > > > >>> >> > > > > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego <isap...@apache.org >> >: >> > > > > >>> >> > > > > >>>> Alexey, if I understand correctly, Ilya does not suggest to >> > > pre-built >> > > > > >>>> binaries, just to ship it with configure script >> pre-generated, >> > > which >> > > > > >>>> is a common practice for autotools packages. Building will be >> > > still >> > > > > >>>> required for the user, but there will be less requirements >> and >> > > > > >>>> possible errors during build. >> > > > > >>>> >> > > > > >>>> I like the idea. Let's do this. >> > > > > >>>> >> > > > > >>>> Best Regards, >> > > > > >>>> Igor >> > > > > >>>> >> > > > > >>>> >> > > > > >>>> On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk < >> > > > > >>>> alexey.goncha...@gmail.com> wrote: >> > > > > >>>> >> > > > > >>>>> To me it doesn't really matter if it will be 'slim' or >> 'lite' :) >> > > I >> > > > > >>> would >> > > > > >>>>> not name it 'core' because indeed it would be confusing >> with the >> > > core >> > > > > >>>>> module name. >> > > > > >>>>> >> > > > > >>>>> Agree that platforms support is useful, so I would keep >> them as >> > > Ilya >> > > > > >>>>> suggested. As for the C++ packages pre-build - let's hear >> out >> > > Igor's >> > > > > >>>>> opinion on this. Pre-built binaries certainly add >> usability, but >> > > I am >> > > > > >>> not >> > > > > >>>>> sure how those binaries should be tested afterwards. >> > > > > >>>>> >> > > > > >>>>> ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov < >> > > akuznet...@apache.org >> > > > > >>> : >> > > > > >>>>> >> > > > > >>>>>> I'm +1 for "SLIM" it is a common name in Docker world. >> > > > > >>>>>> >> > > > > >>>>>> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov < >> > > mr.wei...@gmail.com> >> > > > > >>>> wrote: >> > > > > >>>>>> >> > > > > >>>>>>> +1 for slim binary >> > > > > >>>>>>> Plus docker-slim >> > > > > >>>>>>> Plus RPM / DEB packages modularisation like PHP >> distribution — >> > > > > >> with >> > > > > >>>>> core >> > > > > >>>>>>> and lots of integrations / modules. >> > > > > >>>>>>> >> > > > > >>>>>>>> On 15 Jan 2020, at 17:40, Ilya Kasnacheev < >> > > > > >>>> ilya.kasnach...@gmail.com >> > > > > >>>>>> >> > > > > >>>>>>> wrote: >> > > > > >>>>>>>> >> > > > > >>>>>>>> Hello! >> > > > > >>>>>>>> >> > > > > >>>>>>>> I think we should name it "core" since we already have >> > > > > >>> ignite-core >> > > > > >>>>> and >> > > > > >>>>>> it >> > > > > >>>>>>>> will be confusing. Maybe we should go full 00s and call >> it >> > > > > >>> "lite"? >> > > > > >>>>>>>> >> > > > > >>>>>>>> I also think we should keep both .Net and C++. .Net is >> > > runnable >> > > > > >>> out >> > > > > >>>>> of >> > > > > >>>>>>> box >> > > > > >>>>>>>> which is awesome, and C++ needs building but it is rather >> > > small >> > > > > >>> in >> > > > > >>>>>> source >> > > > > >>>>>>>> form. >> > > > > >>>>>>>> >> > > > > >>>>>>>> I also suggest a different change to build process. >> Let's ship >> > > > > >>> C++ >> > > > > >>>>> with >> > > > > >>>>>>>> automake, etc, already run, for all binary packaging >> options? >> > > > > >>>> WDYT? I >> > > > > >>>>>> can >> > > > > >>>>>>>> assist in build process tuning. >> > > > > >>>>>>>> >> > > > > >>>>>>>> Regards, >> > > > > >>>>>>>> -- >> > > > > >>>>>>>> Ilya Kasnacheev >> > > > > >>>>>>>> >> > > > > >>>>>>>> >> > > > > >>>>>>>> ср, 15 янв. 2020 г. в 17:18, Denis Magda < >> dma...@apache.org>: >> > > > > >>>>>>>> >> > > > > >>>>>>>>> Alex, >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> I'm on your end and support the proposal. Could you also >> > > > > >> clarify >> > > > > >>>> if >> > > > > >>>>>> you >> > > > > >>>>>>>>> suggest we keeping or removing C++ and .NET thick >> clients? >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> Speaking of the naming, how about titling such packages >> as >> > > > > >>> 'core' >> > > > > >>>>>>> instead >> > > > > >>>>>>>>> of 'slim', i.e., 'apache-ignite-core-{version}'? >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> - >> > > > > >>>>>>>>> Denis >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> >> > > > > >>>>>>>>> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev < >> > > > > >>>>>>> ilya.kasnach...@gmail.com >> > > > > >>>>>>>>>> >> > > > > >>>>>>>>> wrote: >> > > > > >>>>>>>>> >> > > > > >>>>>>>>>> Hello! >> > > > > >>>>>>>>>> >> > > > > >>>>>>>>>> Pavel, I believe these JARs are fully covered by the >> list of >> > > > > >>>>> modules >> > > > > >>>>>>>>>> specified above. >> > > > > >>>>>>>>>> >> > > > > >>>>>>>>>> Regards, >> > > > > >>>>>>>>>> -- >> > > > > >>>>>>>>>> Ilya Kasnacheev >> > > > > >>>>>>>>>> >> > > > > >>>>>>>>>> >> > > > > >>>>>>>>>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn < >> > > > > >>>> ptupit...@apache.org >> > > > > >>>>>> : >> > > > > >>>>>>>>>> >> > > > > >>>>>>>>>>> I like the idea, current distribution is certainly >> too big. >> > > > > >>>>>>>>>>> >> > > > > >>>>>>>>>>> Here is a list of jar files we include in NuGet >> package: >> > > > > >>>>>>>>>>> >> > > > > >>>>>>>>>>> cache-api-1.0.0.jar >> > > > > >>>>>>>>>>> commons-codec-1.11.jar >> > > > > >>>>>>>>>>> commons-logging-1.1.1.jar >> > > > > >>>>>>>>>>> h2-1.4.197.jar >> > > > > >>>>>>>>>>> ignite-core-2.9.0-SNAPSHOT.jar >> > > > > >>>>>>>>>>> ignite-indexing-2.9.0-SNAPSHOT.jar >> > > > > >>>>>>>>>>> ignite-shmem-1.0.0.jar >> > > > > >>>>>>>>>>> ignite-spring-2.9.0-SNAPSHOT.jar >> > > > > >>>>>>>>>>> lucene-analyzers-common-7.4.0.jar >> > > > > >>>>>>>>>>> lucene-core-7.4.0.jar >> > > > > >>>>>>>>>>> lucene-queryparser-7.4.0.jar >> > > > > >>>>>>>>>>> spring-aop-4.3.18.RELEASE.jar >> > > > > >>>>>>>>>>> spring-beans-4.3.18.RELEASE.jar >> > > > > >>>>>>>>>>> spring-context-4.3.18.RELEASE.jar >> > > > > >>>>>>>>>>> spring-core-4.3.18.RELEASE.jar >> > > > > >>>>>>>>>>> spring-expression-4.3.18.RELEASE.jar >> > > > > >>>>>>>>>>> spring-jdbc-4.3.18.RELEASE.jar >> > > > > >>>>>>>>>>> spring-tx-4.3.18.RELEASE.jar >> > > > > >>>>>>>>>>> >> > > > > >>>>>>>>>>> Those are required for SQL and Spring configs to work >> > > > > >>> properly, >> > > > > >>>>>>>>>>> maybe we want to include them into the slim distro as >> well. >> > > > > >>>>>>>>>>> >> > > > > >>>>>>>>>>> On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev < >> > > > > >>>>>>>>>> ilya.kasnach...@gmail.com >> > > > > >>>>>>>>>>>> >> > > > > >>>>>>>>>>> wrote: >> > > > > >>>>>>>>>>> >> > > > > >>>>>>>>>>>> Hello! >> > > > > >>>>>>>>>>>> >> > > > > >>>>>>>>>>>> This is a reasonable idea. >> > > > > >>>>>>>>>>>> >> > > > > >>>>>>>>>>>> I think we should also drop benchmarks/ directory >> from >> > > that >> > > > > >>>>> build, >> > > > > >>>>>>>>> it's >> > > > > >>>>>>>>>>> 60M >> > > > > >>>>>>>>>>>> of (potentially vulnerable) JARs that are not needed >> by an >> > > > > >>>>> average >> > > > > >>>>>>>>>>>> developer's use cases. >> > > > > >>>>>>>>>>>> >> > > > > >>>>>>>>>>>> Regards, >> > > > > >>>>>>>>>>>> -- >> > > > > >>>>>>>>>>>> Ilya Kasnacheev >> > > > > >>>>>>>>>>>> >> > > > > >>>>>>>>>>>> >> > > > > >>>>>>>>>>>> ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk < >> > > > > >>>>>>>>>>> alexey.goncha...@gmail.com >> > > > > >>>>>>>>>>>>> : >> > > > > >>>>>>>>>>>> >> > > > > >>>>>>>>>>>>> Igniters, >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>> I would like to discuss with the community a >> possibility >> > > > > >> to >> > > > > >>>>> create >> > > > > >>>>>>>>>>>>> additional 'slim' binary releases and docker images >> for >> > > > > >>> Apache >> > > > > >>>>>>>>>> Ignite. >> > > > > >>>>>>>>>>>> The >> > > > > >>>>>>>>>>>>> reason is two-fold: >> > > > > >>>>>>>>>>>>> * The full set of 3rd party libraries distributed >> with >> > > > > >>> Apache >> > > > > >>>>>>>>> Ignite >> > > > > >>>>>>>>>>>> looks >> > > > > >>>>>>>>>>>>> too large for me. I know there is an ongoing >> activity >> > > > > >>> towards >> > > > > >>>>> more >> > > > > >>>>>>>>>>> clear >> > > > > >>>>>>>>>>>>> Ignite modularization [1][2][3], but this seems to >> be >> > > > > >> quite >> > > > > >>> a >> > > > > >>>>> long >> > > > > >>>>>>>>>>>> process. >> > > > > >>>>>>>>>>>>> On the other hand, creating a slim release may give >> an >> > > > > >>>> immediate >> > > > > >>>>>>>>>>> benefit >> > > > > >>>>>>>>>>>> to >> > > > > >>>>>>>>>>>>> the users who are interested in a smaller image. For >> > > > > >>> example, >> > > > > >>>>>>>>>> removing >> > > > > >>>>>>>>>>>> the >> > > > > >>>>>>>>>>>>> benchmarks alone from the binary release saves 80M. >> > > > > >>>>>>>>>>>>> * As Ilya Kasnacheev demonstrated [4], the more 3rd >> party >> > > > > >>>>>>>>> libraries >> > > > > >>>>>>>>>> we >> > > > > >>>>>>>>>>>>> have, the more potential vulnerabilities will show >> up in >> > > > > >>> audit >> > > > > >>>>>>>>> tools. >> > > > > >>>>>>>>>>>> This >> > > > > >>>>>>>>>>>>> may be a formal barrier for Apache Ignite adoption >> and >> > > > > >>> moving >> > > > > >>>> to >> > > > > >>>>>>>>>>>> production >> > > > > >>>>>>>>>>>>> for many users. Having a slim image with the minimum >> > > > > >> number >> > > > > >>> of >> > > > > >>>>>>>>>>>> dependencies >> > > > > >>>>>>>>>>>>> (yet complete enough to fit the majority of >> use-cases) >> > > > > >>>>>>>>> significantly >> > > > > >>>>>>>>>>>>> reduces this risk. >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>> I wonder what community thinks regarding this idea? >> Given >> > > > > >>> the >> > > > > >>>>>>>>> recent >> > > > > >>>>>>>>>>>> study >> > > > > >>>>>>>>>>>>> of Apache Ignite use-cases, I suggest the following >> list >> > > > > >> of >> > > > > >>>>>> modules >> > > > > >>>>>>>>>> to >> > > > > >>>>>>>>>>> be >> > > > > >>>>>>>>>>>>> included to the slim release/image (a subject to >> discuss, >> > > > > >> of >> > > > > >>>>>>>>> course): >> > > > > >>>>>>>>>>>>> * ignite-core >> > > > > >>>>>>>>>>>>> * ignite-indexing >> > > > > >>>>>>>>>>>>> * ignite-rest-http >> > > > > >>>>>>>>>>>>> * ignite-spring >> > > > > >>>>>>>>>>>>> * ignite-log4j >> > > > > >>>>>>>>>>>>> * ignite-log4j2 >> > > > > >>>>>>>>>>>>> * ignite-slf4j >> > > > > >>>>>>>>>>>>> * ignite-urideploy >> > > > > >>>>>>>>>>>>> * ignite-kubernetes >> > > > > >>>>>>>>>>>>> * ignite-opencensus >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>> [1] >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>> >> > > > > >>>>>>>>>>> >> > > > > >>>>>>>>>> >> > > > > >>>>>>>>> >> > > > > >>>>>>> >> > > > > >>>>>> >> > > > > >>>>> >> > > > > >>>> >> > > > > >>> >> > > > > >> >> > > > > >> > > >> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html >> > > > > >>>>>>>>>>>>> [2] >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>> >> > > > > >>>>>>>>>>> >> > > > > >>>>>>>>>> >> > > > > >>>>>>>>> >> > > > > >>>>>>> >> > > > > >>>>>> >> > > > > >>>>> >> > > > > >>>> >> > > > > >>> >> > > > > >> >> > > > > >> > > >> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html >> > > > > >>>>>>>>>>>>> [3] >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>> >> > > > > >>>>>>>>>>> >> > > > > >>>>>>>>>> >> > > > > >>>>>>>>> >> > > > > >>>>>>> >> > > > > >>>>>> >> > > > > >>>>> >> > > > > >>>> >> > > > > >>> >> > > > > >> >> > > > > >> > > >> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html >> > > > > >>>>>>>>>>>>> [4] >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>> >> > > > > >>>>>>>>>>> >> > > > > >>>>>>>>>> >> > > > > >>>>>>>>> >> > > > > >>>>>>> >> > > > > >>>>>> >> > > > > >>>>> >> > > > > >>>> >> > > > > >>> >> > > > > >> >> > > > > >> > > >> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-td43616i100.html#a44994 >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>>> --AG >> > > > > >>>>>>>>>>>>> >> > > > > >>>>>>>>>>>> >> > > > > >>>>>>>>>>> >> > > > > >>>>>>>>>> >> > > > > >>>>>>>>> >> > > > > >>>>>>> >> > > > > >>>>>>> >> > > > > >>>>>> >> > > > > >>>>>> -- >> > > > > >>>>>> Alexey Kuznetsov >> > > > > >>>>>> >> > > > > >>>>> >> > > > > >>>> >> > > > > >>> >> > > > > >> >> > > > > >> > > > > >> > > > > >> > > >> >
