You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ignite.apache.org by Alexey Goncharuk <al...@gmail.com> on 2020/01/15 10:08:30 UTC
Slim binary release and docker image for Apache Ignite
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
Re: Slim binary release and docker image for Apache Ignite
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello!
I have fixed nightly and release builds. They should now build
apache-ignite-slim. Please contact me if that does not happen.
Regards,
--
Ilya Kasnacheev
ср, 17 июн. 2020 г. в 17:00, Ilya Kasnacheev <il...@gmail.com>:
> 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 <il...@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 <mm...@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 <il...@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 <mm...@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.kasnacheev@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.darlington@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.kasnacheev@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 <dm...@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.goncharuk@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 <isapego@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.goncharuk@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 <
>>> > > akuznetsov@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.weider@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.kasnacheev@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 <
>>> dmagda@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.kasnacheev@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 <
>>> > > > > >>>> ptupitsyn@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.kasnacheev@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.goncharuk@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
>>> > > > > >>>>>>
>>> > > > > >>>>>
>>> > > > > >>>>
>>> > > > > >>>
>>> > > > > >>
>>> > > > >
>>> > > > >
>>> > > > >
>>> > >
>>>
>>
Re: Slim binary release and docker image for Apache Ignite
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <il...@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 <mm...@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 <il...@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 <mm...@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.kasnacheev@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.darlington@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.kasnacheev@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 <dm...@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.goncharuk@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 <isapego@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.goncharuk@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 <
>> > > akuznetsov@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.weider@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.kasnacheev@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 <
>> dmagda@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.kasnacheev@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 <
>> > > > > >>>> ptupitsyn@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.kasnacheev@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.goncharuk@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
>> > > > > >>>>>>
>> > > > > >>>>>
>> > > > > >>>>
>> > > > > >>>
>> > > > > >>
>> > > > >
>> > > > >
>> > > > >
>> > >
>>
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Ilya Kasnacheev <il...@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 <mm...@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 <il...@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 <mm...@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.kasnacheev@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.darlington@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.kasnacheev@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 <dm...@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.goncharuk@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 <is...@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.goncharuk@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 <
> > > akuznetsov@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.weider@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.kasnacheev@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 <
> dmagda@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.kasnacheev@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 <
> > > > > >>>> ptupitsyn@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.kasnacheev@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.goncharuk@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
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > > >
> > >
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Maxim Muzafarov <mm...@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 <il...@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 <mm...@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 <il...@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.darlington@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 <il...@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 <dm...@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.goncharuk@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 <is...@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.goncharuk@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 <
> > akuznetsov@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.weider@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.kasnacheev@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 <dm...@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.kasnacheev@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 <
> > > > >>>> ptupitsyn@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.kasnacheev@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.goncharuk@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
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > > >
> > > >
> >
Re: Slim binary release and docker image for Apache Ignite
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <mm...@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 <il...@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.darlington@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 <il...@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 <dm...@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.goncharuk@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 <is...@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.goncharuk@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 <
> akuznetsov@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.weider@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.kasnacheev@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 <dm...@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.kasnacheev@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 <
> > > >>>> ptupitsyn@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.kasnacheev@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.goncharuk@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
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> > >
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Maxim Muzafarov <mm...@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 <il...@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.darlington@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 <il...@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 <dm...@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.goncharuk@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 <is...@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.goncharuk@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 <akuznetsov@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...@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.kasnacheev@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 <dm...@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.kasnacheev@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 <
> > >>>> ptupitsyn@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.kasnacheev@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.goncharuk@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
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> >
> >
Re: Slim binary release and docker image for Apache Ignite
Posted by Ilya Kasnacheev <il...@gmail.com>.
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.darlington@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 <il...@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 <dm...@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.goncharuk@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 <is...@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.goncharuk@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 <akuznetsov@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...@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.kasnacheev@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 <dm...@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.kasnacheev@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 <
> >>>> ptupitsyn@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.kasnacheev@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.goncharuk@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
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Stephen Darlington <st...@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 <il...@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 <dm...@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.goncharuk@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 <is...@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.goncharuk@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 <akuznetsov@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...@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.kasnacheev@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 <dm...@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.kasnacheev@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 <
>>>> ptupitsyn@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.kasnacheev@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.goncharuk@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
>>>>>>
>>>>>
>>>>
>>>
>>
Re: Slim binary release and docker image for Apache Ignite
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <dm...@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.goncharuk@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 <is...@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.goncharuk@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 <akuznetsov@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...@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.kasnacheev@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 <dm...@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.kasnacheev@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 <
> > > ptupitsyn@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.kasnacheev@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.goncharuk@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
> > > > >
> > > >
> > >
> >
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Denis Magda <dm...@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.goncharuk@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 <is...@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.goncharuk@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 <ak...@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...@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.kasnacheev@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 <dm...@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.kasnacheev@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 <
> > ptupitsyn@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.kasnacheev@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.goncharuk@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
> > > >
> > >
> >
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Alexey Goncharuk <al...@gmail.com>.
Got it, sounds good!
Should we consider the list of modules included in the slim package
finalized?
чт, 16 янв. 2020 г. в 13:13, Igor Sapego <is...@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.goncharuk@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 <ak...@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...@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.kasnacheev@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 <dm...@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.kasnacheev@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 <
> ptupitsyn@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.kasnacheev@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.goncharuk@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
> > >
> >
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Igor Sapego <is...@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.goncharuk@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 <ak...@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...@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.kasnacheev@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 <dm...@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.kasnacheev@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 <ptupitsyn@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.kasnacheev@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.goncharuk@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
> >
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Alexey Goncharuk <al...@gmail.com>.
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 <ak...@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...@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 <il...@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 <dm...@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.kasnacheev@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 <pt...@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.kasnacheev@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.goncharuk@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
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Alexey Kuznetsov <ak...@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...@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 <il...@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 <dm...@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.kasnacheev@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 <pt...@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.kasnacheev@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.goncharuk@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
Re: Slim binary release and docker image for Apache Ignite
Posted by Petr Ivanov <mr...@gmail.com>.
+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 <il...@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 <dm...@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.kasnacheev@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 <pt...@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.kasnacheev@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.goncharuk@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
>>>>>>
>>>>>
>>>>
>>>
>>
Re: Slim binary release and docker image for Apache Ignite
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <dm...@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.kasnacheev@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 <pt...@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.kasnacheev@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.goncharuk@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
> > > > >
> > > >
> > >
> >
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Denis Magda <dm...@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 <il...@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 <pt...@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.kasnacheev@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.goncharuk@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
> > > >
> > >
> >
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <pt...@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.kasnacheev@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.goncharuk@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
> > >
> >
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Pavel Tupitsyn <pt...@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 <il...@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.goncharuk@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
> >
>
Re: Slim binary release and docker image for Apache Ignite
Posted by Ilya Kasnacheev <il...@gmail.com>.
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 <al...@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
>