ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Petr Ivanov <mr.wei...@gmail.com>
Subject Re: Slim binary release and docker image for Apache Ignite
Date Wed, 15 Jan 2020 14:48:30 GMT
+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
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 


Mime
View raw message