ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Kuznetsov <akuznet...@apache.org>
Subject Re: Slim binary release and docker image for Apache Ignite
Date Wed, 15 Jan 2020 15:32:49 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message