Re: Apache Ignite Docker Image Apache ignite/ignite:2.13.0 has many vulnerabilities

[Petr Ivanov]

Hi, Rameish!

Are there vulnerabilities in Apache Ignite's jars, dependency's jars or 
container software?
Also — can you share the way you've run checks, please?


> On 9 Jun 2022, at 08:13, Gadamsetty, Rameish 
>  wrote:
> 
> Hi Team,
> 
> All, We ran Twist lock scan on Docker Image Apache ignite/ignite:2.13.0 and 
> observed many vulnerabilities, Can we get new image with fixes or is there 
> any other way to fix vulnerabilities?
> 
> Thanks & Regards,
> Rameish G.V.N

Apache Ignite Docker Image Apache ignite/ignite:2.13.0 has many vulnerabilities

[Gadamsetty, Rameish]

Hi Team,

All, We ran Twist lock scan on Docker Image Apache ignite/ignite:2.13.0 and 
observed many vulnerabilities, Can we get new image with fixes or is there any 
other way to fix vulnerabilities?

Thanks & Regards,
Rameish G.V.N

[jira] [Created] (IGNITE-14017) We are willing to add s390x support to the docker image.

[Prajakta Chaudhari (Jira)]

Prajakta Chaudhari created IGNITE-14017:
---

 Summary: We are willing to add s390x support to the docker image.
 Key: IGNITE-14017
 URL: https://issues.apache.org/jira/browse/IGNITE-14017
 Project: Ignite
  Issue Type: New Feature
Reporter: Prajakta Chaudhari


We are willing to add s390x support to the docker image. Dockerfile provided on 
Apache Ignite GitHub repository 
(https://github.com/apache/ignite/tree/master/docker/apache-ignite) is working 
fine on s390x architecture. However we could not get any information about how 
does the docker image build and release process work. Can you please give some 
pointers to go ahead with the task?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13935) Update Ignite docker image description

[Denis A. Magda (Jira)]

Denis A. Magda created IGNITE-13935:
---

 Summary: Update Ignite docker image description
 Key: IGNITE-13935
 URL: https://issues.apache.org/jira/browse/IGNITE-13935
 Project: Ignite
  Issue Type: Improvement
Reporter: Denis A. Magda


Apache Ignite is redefined as "a distributed database for in-memory speed and 
high-performance computing".

Update the [docker image 
description|https://hub.docker.com/r/apacheignite/ignite]:
 # The title needs to say "Apache Ignite - Distributed Database"
 # The description of the "What is Apache Ignite?" section needs to be 
identical to a similar section of GitHub's README.md (definition + quick links 
to docs): https://github.com/apache/ignite



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13162) Slim docker image for Apache Ignite

[Ilya Kasnacheev (Jira)]

Ilya Kasnacheev created IGNITE-13162:


 Summary: Slim docker image for Apache Ignite
 Key: IGNITE-13162
 URL: https://issues.apache.org/jira/browse/IGNITE-13162
 Project: Ignite
  Issue Type: New Feature
  Components: build
Reporter: Ilya Kasnacheev


We need to introduce slim docker image in line with slim binary downloadable.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Slim binary release and docker image for Apache Ignite

[Ilya Kasnacheev]

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 :

> 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 :
>
>> 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 :
>>
>>> 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 
>>> 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 :
>>> >
>>> > > Ilya,
>>> > >
>>> > > `ignite-compress` is necessary for `wal page snapshot compression`
>>> [1]
>>> > > which in turn shows very good performance results. So, I suppose,
>>> it's
>>> > > better to include it to the "slim" binary.
>>> > >
>>> > > [1] https://issues.apache.org/jira/browse/IGNITE-11336
>>> > >
>>> > > On Fri, 6 Mar 2020 at 13:31, Ilya Kasnacheev <
>>> ilya.kasnach...@gmail.com>
>>> > > wrote:
>>> > > >
>>> > > > Hello!
>>> > > >
>>> > > > I added these because they are infrastructural to Ignite, as
>>> opposed to
>>> > > > integrations. They are also both very slim.
>>> > > >
>>> > > > Regards,
>>> > > > --
>>> > > > Ilya Kasnacheev
>>> > > >
>>> > > >
>>> > > > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington <
>>> > > > stephen.darling...@gridgain.com>:
>>> > > >
>>> > > > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I
>>> know very
>>> > > few
>>> > > > > people who use either.
>>> > > > >
>>> > > > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev <
>>> ilya.kasnach...@gmail.com>
>>> > > > > wrote:
>>> > > > > >
>>> > > > > > Hello!
>>> > > > > >
>>> > > > > > Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1*
>>> > > > > >
>>> > > > > > I have prepared assemblies for Apache Ignite slim packaging:
>>> > > > > > https://github.com/apache/ignite/tree/ignite-slim
>>> > > > > >
>>> > > > > > It is based on ignite-2.8
>>> > > > > >
>>> > > > > > You can build it with mvn initialize -Prelease,lgpl
>>> > > > > -Dignite.edition=apache-
>>> > > > > > ignite-slim after a normal release build.
>>> > > > > >
>>> > > > > > Please consider the contents of resulting
>>> > > > > > target/bin/apache-ignite-slim-2.8.0-bin.zip
>>> > > > > > It will be a 65M download as opposed to main 455M
>>> apache-ignite-2.8.0
>>> > > > > > distribution.
>>> > > > > >
>>> > > > > > My suggestion is that we can publish it as a post-release step
>>> since
>>> > > it
>>> > > > > > does not affect the release in any way. If we do, we should
>>> probably
>>> > > > > > indicate size for every kind of artifact in our download
>>> section, so
>>> > > our
>>> > > > > > users can choose based on that information.
>>> > > > > >
>>> > > > > > The following modules are included:
>>> > > > > >
>>> > > > > > libs:
>>> > > > > > core/shmem/jcache
>>> > > > > > ignite-indexing
>>> > > > > > ignite-spring
>>> > > > > >
>>> > > > > > libs/optional:
>>> > > > > > ignite-compress  ignite-kubernetes  ignite-log4j2
>>> > > ignite-rest-http
>>> > > > > > ignite-spring-data_2.2
>>> > > > > > ignite-jta   ignite-log4j   ignite-opencensus
>>> ignite-slf4j
>>> > > > > > ignite-urideploy
>>> > > > > >
>>> > > > > > I have kept examples, but removed benchmarks. sqlline still
>>> present,
>>> > > of
>>> > > > > > course.
>>> > > > > >
>>> > > > > > ignite-zookeeper has a lot of dependencies (8M) which we do not
>>> > > update
>>> > > > > > often enough (such as guava, curator, jackson), and which may
>>> form an
>>> > > > > > attack surface.
>>> > > > > >
>>> > > > > > Not a pressing problem for 'integrated' ignite-zookeeper
>>> users, since
>>> > > > > they
>>> > > > > > can re-import these dependencies with more recent versions
>>> using
>>> > > maven or
>>> > > > > > gradle.
>>> > > > > > But for our users who rely on binary package for all JARs,
>>> outdated
>>> > > > > > dependencies may pose a problem.
>>> > > > > >
>>> > > > > > Therefore my opinion is to exclude this dependency and not put
>>> our
>>> > > faith
>>> > > > > on
>>> > > > > > zookeeper dependency version.
>>> > > > > >
>>> 

Re: Slim binary release and docker image for Apache Ignite

[Ilya Kasnacheev]

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 :

> 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 :
>
>> 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 
>> 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 :
>> >
>> > > Ilya,
>> > >
>> > > `ignite-compress` is necessary for `wal page snapshot compression` [1]
>> > > which in turn shows very good performance results. So, I suppose, it's
>> > > better to include it to the "slim" binary.
>> > >
>> > > [1] https://issues.apache.org/jira/browse/IGNITE-11336
>> > >
>> > > On Fri, 6 Mar 2020 at 13:31, Ilya Kasnacheev <
>> ilya.kasnach...@gmail.com>
>> > > wrote:
>> > > >
>> > > > Hello!
>> > > >
>> > > > I added these because they are infrastructural to Ignite, as
>> opposed to
>> > > > integrations. They are also both very slim.
>> > > >
>> > > > Regards,
>> > > > --
>> > > > Ilya Kasnacheev
>> > > >
>> > > >
>> > > > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington <
>> > > > stephen.darling...@gridgain.com>:
>> > > >
>> > > > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I know
>> very
>> > > few
>> > > > > people who use either.
>> > > > >
>> > > > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev <
>> ilya.kasnach...@gmail.com>
>> > > > > wrote:
>> > > > > >
>> > > > > > Hello!
>> > > > > >
>> > > > > > Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1*
>> > > > > >
>> > > > > > I have prepared assemblies for Apache Ignite slim packaging:
>> > > > > > https://github.com/apache/ignite/tree/ignite-slim
>> > > > > >
>> > > > > > It is based on ignite-2.8
>> > > > > >
>> > > > > > You can build it with mvn initialize -Prelease,lgpl
>> > > > > -Dignite.edition=apache-
>> > > > > > ignite-slim after a normal release build.
>> > > > > >
>> > > > > > Please consider the contents of resulting
>> > > > > > target/bin/apache-ignite-slim-2.8.0-bin.zip
>> > > > > > It will be a 65M download as opposed to main 455M
>> apache-ignite-2.8.0
>> > > > > > distribution.
>> > > > > >
>> > > > > > My suggestion is that we can publish it as a post-release step
>> since
>> > > it
>> > > > > > does not affect the release in any way. If we do, we should
>> probably
>> > > > > > indicate size for every kind of artifact in our download
>> section, so
>> > > our
>> > > > > > users can choose based on that information.
>> > > > > >
>> > > > > > The following modules are included:
>> > > > > >
>> > > > > > libs:
>> > > > > > core/shmem/jcache
>> > > > > > ignite-indexing
>> > > > > > ignite-spring
>> > > > > >
>> > > > > > libs/optional:
>> > > > > > ignite-compress  ignite-kubernetes  ignite-log4j2
>> > > ignite-rest-http
>> > > > > > ignite-spring-data_2.2
>> > > > > > ignite-jta   ignite-log4j   ignite-opencensus
>> ignite-slf4j
>> > > > > > ignite-urideploy
>> > > > > >
>> > > > > > I have kept examples, but removed benchmarks. sqlline still
>> present,
>> > > of
>> > > > > > course.
>> > > > > >
>> > > > > > ignite-zookeeper has a lot of dependencies (8M) which we do not
>> > > update
>> > > > > > often enough (such as guava, curator, jackson), and which may
>> form an
>> > > > > > attack surface.
>> > > > > >
>> > > > > > Not a pressing problem for 'integrated' ignite-zookeeper users,
>> since
>> > > > > they
>> > > > > > can re-import these dependencies with more recent versions using
>> > > maven or
>> > > > > > gradle.
>> > > > > > But for our users who rely on binary package for all JARs,
>> outdated
>> > > > > > dependencies may pose a problem.
>> > > > > >
>> > > > > > Therefore my opinion is to exclude this dependency and not put
>> our
>> > > faith
>> > > > > on
>> > > > > > zookeeper dependency version.
>> > > > > >
>> > > > > > The same can be put for ignite-compress, and indeed, I'm not
>> sure if
>> > > we
>> > > > > > should keep it.
>> > > > > >
>> > > > > > We can have an ad-hoc vote here.
>> > > > > >
>> > > > > > I would like to hear arguments for both inclusion and exclusion
>> of
>> > > > > > ignite-zookeeper and ignite-compress into slim package (in any
>> > > > > combination).
>> > > > > >
>> > > 

Re: Potential issues with the latest Ignite Docker image

[Petr Ivanov]

Do you see the error?
Is it telling about missing or wrong certificate or something else?


> On 8 Apr 2020, at 02:18, Denis Magda  wrote:
> 
> Jared, thanks for the details.
> 
> Igniters, is there anyone who had a chance prepared our Docker images for
> releases can look into the reported issue?
> 
> -
> Denis
> 
> 
> On Fri, Apr 3, 2020 at 2:45 PM Jared Gholston  wrote:
> 
>> I'm not exactly sure what version of the ignite docker image we are using,
>> but it is not using BusyBox.  The new version the following fails:
>> 
>> wget https://google.com
>> 
>> this works:
>> 
>> wget http://google.com
>> 
>> 
>> Any https wget fails on the new docker image.  We import several jars using
>> the EXTERNAL_LIBS configuration. The libs are coming from s3 and maven
>> central all of which require https.
>> 
>> I hope that helps,
>> Jared
>> 
>> 
>> 
>> 
>> --
>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>> 

Re: Potential issues with the latest Ignite Docker image

[Denis Magda]

Jared, thanks for the details.

Igniters, is there anyone who had a chance prepared our Docker images for
releases can look into the reported issue?

-
Denis


On Fri, Apr 3, 2020 at 2:45 PM Jared Gholston  wrote:

> I'm not exactly sure what version of the ignite docker image we are using,
> but it is not using BusyBox.  The new version the following fails:
>
> wget https://google.com
>
> this works:
>
> wget http://google.com
>
>
> Any https wget fails on the new docker image.  We import several jars using
> the EXTERNAL_LIBS configuration. The libs are coming from s3 and maven
> central all of which require https.
>
> I hope that helps,
> Jared
>
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

Re: Potential issues with the latest Ignite Docker image

[Jared Gholston]

I'm not exactly sure what version of the ignite docker image we are using,
but it is not using BusyBox.  The new version the following fails:

wget https://google.com

this works:

wget http://google.com


Any https wget fails on the new docker image.  We import several jars using
the EXTERNAL_LIBS configuration. The libs are coming from s3 and maven
central all of which require https. 

I hope that helps,
Jared




--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Potential issues with the latest Ignite Docker image

[Denis Magda]

Igniters,

One of our users reported an issue related to the latest docker image:

https://twitter.com/jarbot/status/1245945256756957184?s=21

Can someone check what exactly was broken?

Denis


-- 
-
Denis

Re: Slim binary release and docker image for Apache Ignite

[Ilya Kasnacheev]

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 :

> 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 
> 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 :
> >
> > > Ilya,
> > >
> > > `ignite-compress` is necessary for `wal page snapshot compression` [1]
> > > which in turn shows very good performance results. So, I suppose, it's
> > > better to include it to the "slim" binary.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-11336
> > >
> > > On Fri, 6 Mar 2020 at 13:31, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> > > wrote:
> > > >
> > > > Hello!
> > > >
> > > > I added these because they are infrastructural to Ignite, as opposed
> to
> > > > integrations. They are also both very slim.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington <
> > > > stephen.darling...@gridgain.com>:
> > > >
> > > > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I know
> very
> > > few
> > > > > people who use either.
> > > > >
> > > > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Hello!
> > > > > >
> > > > > > Re-posting from *[DISCUSSION] Release Apache Ignite 2.8.0 RC1*
> > > > > >
> > > > > > I have prepared assemblies for Apache Ignite slim packaging:
> > > > > > https://github.com/apache/ignite/tree/ignite-slim
> > > > > >
> > > > > > It is based on ignite-2.8
> > > > > >
> > > > > > You can build it with mvn initialize -Prelease,lgpl
> > > > > -Dignite.edition=apache-
> > > > > > ignite-slim after a normal release build.
> > > > > >
> > > > > > Please consider the contents of resulting
> > > > > > target/bin/apache-ignite-slim-2.8.0-bin.zip
> > > > > > It will be a 65M download as opposed to main 455M
> apache-ignite-2.8.0
> > > > > > distribution.
> > > > > >
> > > > > > My suggestion is that we can publish it as a post-release step
> since
> > > it
> > > > > > does not affect the release in any way. If we do, we should
> probably
> > > > > > indicate size for every kind of artifact in our download
> section, so
> > > our
> > > > > > users can choose based on that information.
> > > > > >
> > > > > > The following modules are included:
> > > > > >
> > > > > > libs:
> > > > > > core/shmem/jcache
> > > > > > ignite-indexing
> > > > > > ignite-spring
> > > > > >
> > > > > > libs/optional:
> > > > > > ignite-compress  ignite-kubernetes  ignite-log4j2
> > > ignite-rest-http
> > > > > > ignite-spring-data_2.2
> > > > > > ignite-jta   ignite-log4j   ignite-opencensus
> ignite-slf4j
> > > > > > ignite-urideploy
> > > > > >
> > > > > > I have kept examples, but removed benchmarks. sqlline still
> present,
> > > of
> > > > > > course.
> > > > > >
> > > > > > ignite-zookeeper has a lot of dependencies (8M) which we do not
> > > update
> > > > > > often enough (such as guava, curator, jackson), and which may
> form an
> > > > > > attack surface.
> > > > > >
> > > > > > Not a pressing problem for 'integrated' ignite-zookeeper users,
> since
> > > > > they
> > > > > > can re-import these dependencies with more recent versions using
> > > maven or
> > > > > > gradle.
> > > > > > But for our users who rely on binary package for all JARs,
> outdated
> > > > > > dependencies may pose a problem.
> > > > > >
> > > > > > Therefore my opinion is to exclude this dependency and not put
> our
> > > faith
> > > > > on
> > > > > > zookeeper dependency version.
> > > > > >
> > > > > > The same can be put for ignite-compress, and indeed, I'm not
> sure if
> > > we
> > > > > > should keep it.
> > > > > >
> > > > > > We can have an ad-hoc vote here.
> > > > > >
> > > > > > I would like to hear arguments for both inclusion and exclusion
> of
> > > > > > ignite-zookeeper and ignite-compress into slim package (in any
> > > > > combination).
> > > > > >
> > > > > > I would also like to know if you want a formal vote on the issue.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > пн, 27 янв. 2020 г. в 21:13, Denis Magda :
> > > > > >
> > > > > >> Alex, could you please list all the modules that will be
> excluded?
> > > It
> > > > > will
> > > > > >> help to confirm we haven't dumped anything essential.
> > > > > >>
> > 

Re: Slim binary release and docker image for Apache Ignite

[Maxim Muzafarov]

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  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 :
>
> > 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 
> > wrote:
> > >
> > > Hello!
> > >
> > > I added these because they are infrastructural to Ignite, as opposed to
> > > integrations. They are also both very slim.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington <
> > > stephen.darling...@gridgain.com>:
> > >
> > > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I know very
> > few
> > > > people who use either.
> > > >
> > > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev 
> > > > 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 :
> > > > >
> > > > >> Alex, could you please list all the modules that will be excluded?
> > It
> > > > will
> > > > >> help to confirm we haven't dumped anything essential.
> > > > >>
> > > > >> -
> > > > >> Denis
> > > > >>
> > > > >>
> > > > >> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk <
> > > > >> alexey.goncha...@gmail.com> wrote:
> > > > >>
> > > > >>> Got it, sounds good!
> > > > >>> Should we consider the list of modules included in the slim package
> > > > >>> finalized?
> > > > >>>
> > > > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego :
> > > > >>>
> > > >  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 

[jira] [Created] (IGNITE-12765) Slim binary release and docker image for Apache Ignite

[Maxim Muzafarov (Jira)]

Maxim Muzafarov created IGNITE-12765:


 Summary: Slim binary release and docker image for Apache Ignite
 Key: IGNITE-12765
 URL: https://issues.apache.org/jira/browse/IGNITE-12765
 Project: Ignite
  Issue Type: Task
Reporter: Maxim Muzafarov
 Fix For: 2.8.1


1. Prepare Apache Ignite "slim" distribution (example: 
https://github.com/apache/ignite/tree/ignite-slim)
2. Update configuration and check Apache Ignite RELEASE TeamCity Suite 
according to a new additional package distribution.

See - discussion on dev-list
http://apache-ignite-developers.2346864.n4.nabble.com/Slim-binary-release-and-docker-image-for-Apache-Ignite-td45110.html

{code}
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

 * ignite-core
 * ignite-indexing
 * ignite-rest-http
 * ignite-spring
 * ignite-log4j
 * ignite-log4j2
 * ignite-slf4j
 * ignite-urideploy
 * ignite-kubernetes
 * ignite-opencensus
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Slim binary release and docker image for Apache Ignite

[Ilya Kasnacheev]

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 :

> 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 
> wrote:
> >
> > Hello!
> >
> > I added these because they are infrastructural to Ignite, as opposed to
> > integrations. They are also both very slim.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 6 мар. 2020 г. в 13:25, Stephen Darlington <
> > stephen.darling...@gridgain.com>:
> >
> > > Why ignite-jta and ignite-urideploy? Anecdotally at least, I know very
> few
> > > people who use either.
> > >
> > > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev 
> > > 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 :
> > > >
> > > >> Alex, could you please list all the modules that will be excluded?
> It
> > > will
> > > >> help to confirm we haven't dumped anything essential.
> > > >>
> > > >> -
> > > >> Denis
> > > >>
> > > >>
> > > >> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk <
> > > >> alexey.goncha...@gmail.com> wrote:
> > > >>
> > > >>> Got it, sounds good!
> > > >>> Should we consider the list of modules included in the slim package
> > > >>> finalized?
> > > >>>
> > > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego :
> > > >>>
> > >  Alexey, if I understand correctly, Ilya does not suggest to
> pre-built
> > >  binaries, just to ship it with configure script pre-generated,
> which
> > >  is a common practice for autotools packages. Building will be
> still
> > >  required for the user, but there will be less requirements and
> > >  possible errors during build.
> > > 
> > >  I like the idea. Let's do this.
> > > 
> > >  Best Regards,
> > >  Igor
> > > 
> > > 
> > >  On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk <
> > >  alexey.goncha...@gmail.com> wrote:
> > > 
> > > > To me it doesn't really matter if it will be 'slim' or 'lite' :)
> I
> > > >>> would
> > > > not name it 'core' because indeed 

Re: Slim binary release and docker image for Apache Ignite

[Maxim Muzafarov]

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  wrote:
>
> Hello!
>
> I added these because they are infrastructural to Ignite, as opposed to
> integrations. They are also both very slim.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> пт, 6 мар. 2020 г. в 13:25, Stephen Darlington <
> stephen.darling...@gridgain.com>:
>
> > Why ignite-jta and ignite-urideploy? Anecdotally at least, I know very few
> > people who use either.
> >
> > > On 6 Mar 2020, at 11:09, Ilya Kasnacheev 
> > 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 :
> > >
> > >> Alex, could you please list all the modules that will be excluded? It
> > will
> > >> help to confirm we haven't dumped anything essential.
> > >>
> > >> -
> > >> Denis
> > >>
> > >>
> > >> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk <
> > >> alexey.goncha...@gmail.com> wrote:
> > >>
> > >>> Got it, sounds good!
> > >>> Should we consider the list of modules included in the slim package
> > >>> finalized?
> > >>>
> > >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego :
> > >>>
> >  Alexey, if I understand correctly, Ilya does not suggest to pre-built
> >  binaries, just to ship it with configure script pre-generated, which
> >  is a common practice for autotools packages. Building will be still
> >  required for the user, but there will be less requirements and
> >  possible errors during build.
> > 
> >  I like the idea. Let's do this.
> > 
> >  Best Regards,
> >  Igor
> > 
> > 
> >  On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk <
> >  alexey.goncha...@gmail.com> wrote:
> > 
> > > To me it doesn't really matter if it will be 'slim' or 'lite' :) I
> > >>> would
> > > not name it 'core' because indeed it would be confusing with the core
> > > module name.
> > >
> > > Agree that platforms support is useful, so I would keep them as Ilya
> > > suggested. As for the C++ packages pre-build - let's hear out Igor's
> > > opinion on this. Pre-built binaries certainly add usability, but I am
> > >>> not
> > > sure how those binaries should be tested afterwards.
> > >
> > > ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov  > >>> :
> > >
> > >> I'm +1 for "SLIM" it is a common name in Docker world.
> > >>
> > >> On Wed, Jan 15, 2020 at 9:48 PM Petr 

Re: Slim binary release and docker image for Apache Ignite

[Ilya Kasnacheev]

Hello!

I added these because they are infrastructural to Ignite, as opposed to
integrations. They are also both very slim.

Regards,
-- 
Ilya Kasnacheev


пт, 6 мар. 2020 г. в 13:25, Stephen Darlington <
stephen.darling...@gridgain.com>:

> Why ignite-jta and ignite-urideploy? Anecdotally at least, I know very few
> people who use either.
>
> > On 6 Mar 2020, at 11:09, Ilya Kasnacheev 
> 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 :
> >
> >> Alex, could you please list all the modules that will be excluded? It
> will
> >> help to confirm we haven't dumped anything essential.
> >>
> >> -
> >> Denis
> >>
> >>
> >> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk <
> >> alexey.goncha...@gmail.com> wrote:
> >>
> >>> Got it, sounds good!
> >>> Should we consider the list of modules included in the slim package
> >>> finalized?
> >>>
> >>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego :
> >>>
>  Alexey, if I understand correctly, Ilya does not suggest to pre-built
>  binaries, just to ship it with configure script pre-generated, which
>  is a common practice for autotools packages. Building will be still
>  required for the user, but there will be less requirements and
>  possible errors during build.
> 
>  I like the idea. Let's do this.
> 
>  Best Regards,
>  Igor
> 
> 
>  On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk <
>  alexey.goncha...@gmail.com> wrote:
> 
> > To me it doesn't really matter if it will be 'slim' or 'lite' :) I
> >>> would
> > not name it 'core' because indeed it would be confusing with the core
> > module name.
> >
> > Agree that platforms support is useful, so I would keep them as Ilya
> > suggested. As for the C++ packages pre-build - let's hear out Igor's
> > opinion on this. Pre-built binaries certainly add usability, but I am
> >>> not
> > sure how those binaries should be tested afterwards.
> >
> > ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov  >>> :
> >
> >> I'm +1 for "SLIM" it is a common name in Docker world.
> >>
> >> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov 
>  wrote:
> >>
> >>> +1 for slim binary
> >>> Plus docker-slim
> >>> Plus RPM / DEB packages modularisation like PHP distribution —
> >> with
> > core
> >>> and lots of integrations / modules.
> >>>
>  On 15 Jan 2020, at 17:40, Ilya Kasnacheev <
>  ilya.kasnach...@gmail.com
> >>
> >>> wrote:
> 
>  Hello!
> 
>  I think we should name it "core" since we already have
> >>> ignite-core
> > and
> >> it
>  will be confusing. Maybe we should go full 00s and call it
> >>> 

Re: Slim binary release and docker image for Apache Ignite

[Stephen Darlington]

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  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 :
> 
>> Alex, could you please list all the modules that will be excluded? It will
>> help to confirm we haven't dumped anything essential.
>> 
>> -
>> Denis
>> 
>> 
>> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk <
>> alexey.goncha...@gmail.com> wrote:
>> 
>>> Got it, sounds good!
>>> Should we consider the list of modules included in the slim package
>>> finalized?
>>> 
>>> чт, 16 янв. 2020 г. в 13:13, Igor Sapego :
>>> 
 Alexey, if I understand correctly, Ilya does not suggest to pre-built
 binaries, just to ship it with configure script pre-generated, which
 is a common practice for autotools packages. Building will be still
 required for the user, but there will be less requirements and
 possible errors during build.
 
 I like the idea. Let's do this.
 
 Best Regards,
 Igor
 
 
 On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk <
 alexey.goncha...@gmail.com> wrote:
 
> To me it doesn't really matter if it will be 'slim' or 'lite' :) I
>>> would
> not name it 'core' because indeed it would be confusing with the core
> module name.
> 
> Agree that platforms support is useful, so I would keep them as Ilya
> suggested. As for the C++ packages pre-build - let's hear out Igor's
> opinion on this. Pre-built binaries certainly add usability, but I am
>>> not
> sure how those binaries should be tested afterwards.
> 
> ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov >> :
> 
>> I'm +1 for "SLIM" it is a common name in Docker world.
>> 
>> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov 
 wrote:
>> 
>>> +1 for slim binary
>>> Plus docker-slim
>>> Plus RPM / DEB packages modularisation like PHP distribution —
>> with
> core
>>> and lots of integrations / modules.
>>> 
 On 15 Jan 2020, at 17:40, Ilya Kasnacheev <
 ilya.kasnach...@gmail.com
>> 
>>> wrote:
 
 Hello!
 
 I think we should name it "core" since we already have
>>> ignite-core
> and
>> it
 will be confusing. Maybe we should go full 00s and call it
>>> "lite"?
 
 I also think we should keep both .Net and C++. .Net is runnable
>>> out
> of
>>> box
 which is awesome, and C++ needs building but it is rather small
>>> in
>> source
 form.
 
 I also suggest a different change to build process. Let's ship
>>> C++
> with
 automake, etc, already run, for all binary packaging options?
 WDYT? I
>> can
 assist in build process tuning.
 
 Regards,

Re: Slim binary release and docker image for Apache Ignite

[Ilya Kasnacheev]

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 :

> Alex, could you please list all the modules that will be excluded? It will
> help to confirm we haven't dumped anything essential.
>
> -
> Denis
>
>
> On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > Got it, sounds good!
> > Should we consider the list of modules included in the slim package
> > finalized?
> >
> > чт, 16 янв. 2020 г. в 13:13, Igor Sapego :
> >
> > > Alexey, if I understand correctly, Ilya does not suggest to pre-built
> > > binaries, just to ship it with configure script pre-generated, which
> > > is a common practice for autotools packages. Building will be still
> > > required for the user, but there will be less requirements and
> > > possible errors during build.
> > >
> > > I like the idea. Let's do this.
> > >
> > > Best Regards,
> > > Igor
> > >
> > >
> > > On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > > > To me it doesn't really matter if it will be 'slim' or 'lite' :) I
> > would
> > > > not name it 'core' because indeed it would be confusing with the core
> > > > module name.
> > > >
> > > > Agree that platforms support is useful, so I would keep them as Ilya
> > > > suggested. As for the C++ packages pre-build - let's hear out Igor's
> > > > opinion on this. Pre-built binaries certainly add usability, but I am
> > not
> > > > sure how those binaries should be tested afterwards.
> > > >
> > > > ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov  >:
> > > >
> > > > > I'm +1 for "SLIM" it is a common name in Docker world.
> > > > >
> > > > > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov 
> > > wrote:
> > > > >
> > > > > > +1 for slim binary
> > > > > > Plus docker-slim
> > > > > > Plus RPM / DEB packages modularisation like PHP distribution —
> with
> > > > core
> > > > > > and lots of integrations / modules.
> > > > > >
> > > > > > > On 15 Jan 2020, at 17:40, Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com
> > > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > Hello!
> > > > > > >
> > > > > > > I think we should name it "core" since we already have
> > ignite-core
> > > > and
> > > > > it
> > > > > > > will be confusing. Maybe we should go full 00s and call it
> > "lite"?
> > > > > > >
> > > > > > > I also think we should keep both .Net and C++. .Net is runnable
> > out
> > > > of
> > > > > > box
> > > > > > > which is awesome, and C++ needs building but it is rather small
> > in
> > > > > source
> > > > > > > form.
> > > > > > >
> > > > > > > I also suggest a different change to build process. Let's ship
> > C++
> > > > with
> > > > > > > automake, etc, already run, for all binary packaging options?
> > > WDYT? I
> > > > > can
> > > > > > > assist in build process tuning.
> > > > > > >
> > > > > > > Regards,
> > > > > > > --
> > > > > > > Ilya Kasnacheev
> > > > > > >
> > > > > > >
> > > > > > > ср, 15 янв. 2020 г. в 17:18, Denis Magda :
> > > > > > >
> 

Re: Slim binary release and docker image for Apache Ignite

[Denis Magda]

Alex, could you please list all the modules that will be excluded? It will
help to confirm we haven't dumped anything essential.

-
Denis


On Mon, Jan 27, 2020 at 12:33 AM Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Got it, sounds good!
> Should we consider the list of modules included in the slim package
> finalized?
>
> чт, 16 янв. 2020 г. в 13:13, Igor Sapego :
>
> > Alexey, if I understand correctly, Ilya does not suggest to pre-built
> > binaries, just to ship it with configure script pre-generated, which
> > is a common practice for autotools packages. Building will be still
> > required for the user, but there will be less requirements and
> > possible errors during build.
> >
> > I like the idea. Let's do this.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> > > To me it doesn't really matter if it will be 'slim' or 'lite' :) I
> would
> > > not name it 'core' because indeed it would be confusing with the core
> > > module name.
> > >
> > > Agree that platforms support is useful, so I would keep them as Ilya
> > > suggested. As for the C++ packages pre-build - let's hear out Igor's
> > > opinion on this. Pre-built binaries certainly add usability, but I am
> not
> > > sure how those binaries should be tested afterwards.
> > >
> > > ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov :
> > >
> > > > I'm +1 for "SLIM" it is a common name in Docker world.
> > > >
> > > > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov 
> > wrote:
> > > >
> > > > > +1 for slim binary
> > > > > Plus docker-slim
> > > > > Plus RPM / DEB packages modularisation like PHP distribution — with
> > > core
> > > > > and lots of integrations / modules.
> > > > >
> > > > > > On 15 Jan 2020, at 17:40, Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > > >
> > > > > wrote:
> > > > > >
> > > > > > Hello!
> > > > > >
> > > > > > I think we should name it "core" since we already have
> ignite-core
> > > and
> > > > it
> > > > > > will be confusing. Maybe we should go full 00s and call it
> "lite"?
> > > > > >
> > > > > > I also think we should keep both .Net and C++. .Net is runnable
> out
> > > of
> > > > > box
> > > > > > which is awesome, and C++ needs building but it is rather small
> in
> > > > source
> > > > > > form.
> > > > > >
> > > > > > I also suggest a different change to build process. Let's ship
> C++
> > > with
> > > > > > automake, etc, already run, for all binary packaging options?
> > WDYT? I
> > > > can
> > > > > > assist in build process tuning.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Ilya Kasnacheev
> > > > > >
> > > > > >
> > > > > > ср, 15 янв. 2020 г. в 17:18, Denis Magda :
> > > > > >
> > > > > >> Alex,
> > > > > >>
> > > > > >> I'm on your end and support the proposal. Could you also clarify
> > if
> > > > you
> > > > > >> suggest we keeping or removing C++ and .NET thick clients?
> > > > > >>
> > > > > >> Speaking of the naming, how about titling such packages as
> 'core'
> > > > > instead
> > > > > >> of 'slim', i.e., 'apache-ignite-core-{version}'?
> > > > > >>
> > > > > >>
> > > > > >> -
> > > > > >> Denis
> > > > > >>
> > > > > >>
> > > > > >> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev <
> > > > > ilya.kasnach...@gmail.com
> > > > > >>>
> > > > > >> wrote:
> > > > > >>
> > > > > >>> Hello!
> > > > > >>>
> > > > > >>> Pavel, I believe these JARs are fully covered by the list of
> > > modules
> > > > > >>> specified above.
> > > > > >>>
> > > > > >>> Regards,
> > > > > >>> --
> > > > > >>> Ilya Kasnacheev
> > > > > >>>
> > > > > >>>
> > > > > >>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn <
> > ptupit...@apache.org
> > > >:
> > > > > >>>
> > > > >  I like the idea, current distribution is certainly too big.
> > > > > 
> > > > >  Here is a list of jar files we include in NuGet package:
> > > > > 
> > > > >  cache-api-1.0.0.jar
> > > > >  commons-codec-1.11.jar
> > > > >  commons-logging-1.1.1.jar
> > > > >  h2-1.4.197.jar
> > > > >  ignite-core-2.9.0-SNAPSHOT.jar
> > > > >  ignite-indexing-2.9.0-SNAPSHOT.jar
> > > > >  ignite-shmem-1.0.0.jar
> > > > >  ignite-spring-2.9.0-SNAPSHOT.jar
> > > > >  lucene-analyzers-common-7.4.0.jar
> > > > >  lucene-core-7.4.0.jar
> > > > >  lucene-queryparser-7.4.0.jar
> > > > >  spring-aop-4.3.18.RELEASE.jar
> > > > >  spring-beans-4.3.18.RELEASE.jar
> > > > >  spring-context-4.3.18.RELEASE.jar
> > > > >  spring-core-4.3.18.RELEASE.jar
> > > > >  spring-expression-4.3.18.RELEASE.jar
> > > > >  spring-jdbc-4.3.18.RELEASE.jar
> > > > >  spring-tx-4.3.18.RELEASE.jar
> > > > > 
> > > > >  Those are required for SQL and Spring configs to work
> properly,
> > > > >  maybe we want to include them into the slim distro as well.
> > > > > 
> > > > >  On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> > > > > >>> ilya.kasnach...@gmail.com
> > > > > >
> 

Re: Slim binary release and docker image for Apache Ignite

[Alexey Goncharuk]

Got it, sounds good!
Should we consider the list of modules included in the slim package
finalized?

чт, 16 янв. 2020 г. в 13:13, Igor Sapego :

> Alexey, if I understand correctly, Ilya does not suggest to pre-built
> binaries, just to ship it with configure script pre-generated, which
> is a common practice for autotools packages. Building will be still
> required for the user, but there will be less requirements and
> possible errors during build.
>
> I like the idea. Let's do this.
>
> Best Regards,
> Igor
>
>
> On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
> > To me it doesn't really matter if it will be 'slim' or 'lite' :) I would
> > not name it 'core' because indeed it would be confusing with the core
> > module name.
> >
> > Agree that platforms support is useful, so I would keep them as Ilya
> > suggested. As for the C++ packages pre-build - let's hear out Igor's
> > opinion on this. Pre-built binaries certainly add usability, but I am not
> > sure how those binaries should be tested afterwards.
> >
> > ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov :
> >
> > > I'm +1 for "SLIM" it is a common name in Docker world.
> > >
> > > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov 
> wrote:
> > >
> > > > +1 for slim binary
> > > > Plus docker-slim
> > > > Plus RPM / DEB packages modularisation like PHP distribution — with
> > core
> > > > and lots of integrations / modules.
> > > >
> > > > > On 15 Jan 2020, at 17:40, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >
> > > > wrote:
> > > > >
> > > > > Hello!
> > > > >
> > > > > I think we should name it "core" since we already have ignite-core
> > and
> > > it
> > > > > will be confusing. Maybe we should go full 00s and call it "lite"?
> > > > >
> > > > > I also think we should keep both .Net and C++. .Net is runnable out
> > of
> > > > box
> > > > > which is awesome, and C++ needs building but it is rather small in
> > > source
> > > > > form.
> > > > >
> > > > > I also suggest a different change to build process. Let's ship C++
> > with
> > > > > automake, etc, already run, for all binary packaging options?
> WDYT? I
> > > can
> > > > > assist in build process tuning.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > ср, 15 янв. 2020 г. в 17:18, Denis Magda :
> > > > >
> > > > >> Alex,
> > > > >>
> > > > >> I'm on your end and support the proposal. Could you also clarify
> if
> > > you
> > > > >> suggest we keeping or removing C++ and .NET thick clients?
> > > > >>
> > > > >> Speaking of the naming, how about titling such packages as 'core'
> > > > instead
> > > > >> of 'slim', i.e., 'apache-ignite-core-{version}'?
> > > > >>
> > > > >>
> > > > >> -
> > > > >> Denis
> > > > >>
> > > > >>
> > > > >> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev <
> > > > ilya.kasnach...@gmail.com
> > > > >>>
> > > > >> wrote:
> > > > >>
> > > > >>> Hello!
> > > > >>>
> > > > >>> Pavel, I believe these JARs are fully covered by the list of
> > modules
> > > > >>> specified above.
> > > > >>>
> > > > >>> Regards,
> > > > >>> --
> > > > >>> Ilya Kasnacheev
> > > > >>>
> > > > >>>
> > > > >>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn <
> ptupit...@apache.org
> > >:
> > > > >>>
> > > >  I like the idea, current distribution is certainly too big.
> > > > 
> > > >  Here is a list of jar files we include in NuGet package:
> > > > 
> > > >  cache-api-1.0.0.jar
> > > >  commons-codec-1.11.jar
> > > >  commons-logging-1.1.1.jar
> > > >  h2-1.4.197.jar
> > > >  ignite-core-2.9.0-SNAPSHOT.jar
> > > >  ignite-indexing-2.9.0-SNAPSHOT.jar
> > > >  ignite-shmem-1.0.0.jar
> > > >  ignite-spring-2.9.0-SNAPSHOT.jar
> > > >  lucene-analyzers-common-7.4.0.jar
> > > >  lucene-core-7.4.0.jar
> > > >  lucene-queryparser-7.4.0.jar
> > > >  spring-aop-4.3.18.RELEASE.jar
> > > >  spring-beans-4.3.18.RELEASE.jar
> > > >  spring-context-4.3.18.RELEASE.jar
> > > >  spring-core-4.3.18.RELEASE.jar
> > > >  spring-expression-4.3.18.RELEASE.jar
> > > >  spring-jdbc-4.3.18.RELEASE.jar
> > > >  spring-tx-4.3.18.RELEASE.jar
> > > > 
> > > >  Those are required for SQL and Spring configs to work properly,
> > > >  maybe we want to include them into the slim distro as well.
> > > > 
> > > >  On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> > > > >>> ilya.kasnach...@gmail.com
> > > > >
> > > >  wrote:
> > > > 
> > > > > Hello!
> > > > >
> > > > > This is a reasonable idea.
> > > > >
> > > > > I think we should also drop benchmarks/ directory from that
> > build,
> > > > >> it's
> > > >  60M
> > > > > of (potentially vulnerable) JARs that are not needed by an
> > average
> > > > > developer's use cases.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Ilya Kasnacheev
> > > > >
> > > > >
> > > > > ср, 15 янв. 2020 г. в 13:10, Alexey 

Re: Slim binary release and docker image for Apache Ignite

[Igor Sapego]

Alexey, if I understand correctly, Ilya does not suggest to pre-built
binaries, just to ship it with configure script pre-generated, which
is a common practice for autotools packages. Building will be still
required for the user, but there will be less requirements and
possible errors during build.

I like the idea. Let's do this.

Best Regards,
Igor


On Thu, Jan 16, 2020 at 11:57 AM Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> To me it doesn't really matter if it will be 'slim' or 'lite' :) I would
> not name it 'core' because indeed it would be confusing with the core
> module name.
>
> Agree that platforms support is useful, so I would keep them as Ilya
> suggested. As for the C++ packages pre-build - let's hear out Igor's
> opinion on this. Pre-built binaries certainly add usability, but I am not
> sure how those binaries should be tested afterwards.
>
> ср, 15 янв. 2020 г. в 18:33, Alexey Kuznetsov :
>
> > I'm +1 for "SLIM" it is a common name in Docker world.
> >
> > On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov  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  >
> > > 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 :
> > > >
> > > >> Alex,
> > > >>
> > > >> I'm on your end and support the proposal. Could you also clarify if
> > you
> > > >> suggest we keeping or removing C++ and .NET thick clients?
> > > >>
> > > >> Speaking of the naming, how about titling such packages as 'core'
> > > instead
> > > >> of 'slim', i.e., 'apache-ignite-core-{version}'?
> > > >>
> > > >>
> > > >> -
> > > >> Denis
> > > >>
> > > >>
> > > >> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com
> > > >>>
> > > >> wrote:
> > > >>
> > > >>> Hello!
> > > >>>
> > > >>> Pavel, I believe these JARs are fully covered by the list of
> modules
> > > >>> specified above.
> > > >>>
> > > >>> Regards,
> > > >>> --
> > > >>> Ilya Kasnacheev
> > > >>>
> > > >>>
> > > >>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn  >:
> > > >>>
> > >  I like the idea, current distribution is certainly too big.
> > > 
> > >  Here is a list of jar files we include in NuGet package:
> > > 
> > >  cache-api-1.0.0.jar
> > >  commons-codec-1.11.jar
> > >  commons-logging-1.1.1.jar
> > >  h2-1.4.197.jar
> > >  ignite-core-2.9.0-SNAPSHOT.jar
> > >  ignite-indexing-2.9.0-SNAPSHOT.jar
> > >  ignite-shmem-1.0.0.jar
> > >  ignite-spring-2.9.0-SNAPSHOT.jar
> > >  lucene-analyzers-common-7.4.0.jar
> > >  lucene-core-7.4.0.jar
> > >  lucene-queryparser-7.4.0.jar
> > >  spring-aop-4.3.18.RELEASE.jar
> > >  spring-beans-4.3.18.RELEASE.jar
> > >  spring-context-4.3.18.RELEASE.jar
> > >  spring-core-4.3.18.RELEASE.jar
> > >  spring-expression-4.3.18.RELEASE.jar
> > >  spring-jdbc-4.3.18.RELEASE.jar
> > >  spring-tx-4.3.18.RELEASE.jar
> > > 
> > >  Those are required for SQL and Spring configs to work properly,
> > >  maybe we want to include them into the slim distro as well.
> > > 
> > >  On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> > > >>> ilya.kasnach...@gmail.com
> > > >
> > >  wrote:
> > > 
> > > > Hello!
> > > >
> > > > This is a reasonable idea.
> > > >
> > > > I think we should also drop benchmarks/ directory from that
> build,
> > > >> it's
> > >  60M
> > > > of (potentially vulnerable) JARs that are not needed by an
> average
> > > > developer's use cases.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
> > >  alexey.goncha...@gmail.com
> > > >> :
> > > >
> > > >> Igniters,
> > > >>
> > > >> I would like to discuss with the community a possibility to
> create
> > > >> additional 'slim' binary releases and docker images for Apache
> > > >>> Ignite.
> > > > The
> > > >> reason is two-fold:
> > > >> * The full set of 3rd party libraries distributed with Apache
> > > >> Ignite
> > > > looks
> > > >> too large for me. I know there is an ongoing 

Re: Slim binary release and docker image for Apache Ignite

[Alexey Goncharuk]

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 :

> I'm +1 for "SLIM" it is a common name in Docker world.
>
> On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov  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 
> > 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 :
> > >
> > >> Alex,
> > >>
> > >> I'm on your end and support the proposal. Could you also clarify if
> you
> > >> suggest we keeping or removing C++ and .NET thick clients?
> > >>
> > >> Speaking of the naming, how about titling such packages as 'core'
> > instead
> > >> of 'slim', i.e., 'apache-ignite-core-{version}'?
> > >>
> > >>
> > >> -
> > >> Denis
> > >>
> > >>
> > >> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > >>>
> > >> wrote:
> > >>
> > >>> Hello!
> > >>>
> > >>> Pavel, I believe these JARs are fully covered by the list of modules
> > >>> specified above.
> > >>>
> > >>> Regards,
> > >>> --
> > >>> Ilya Kasnacheev
> > >>>
> > >>>
> > >>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn :
> > >>>
> >  I like the idea, current distribution is certainly too big.
> > 
> >  Here is a list of jar files we include in NuGet package:
> > 
> >  cache-api-1.0.0.jar
> >  commons-codec-1.11.jar
> >  commons-logging-1.1.1.jar
> >  h2-1.4.197.jar
> >  ignite-core-2.9.0-SNAPSHOT.jar
> >  ignite-indexing-2.9.0-SNAPSHOT.jar
> >  ignite-shmem-1.0.0.jar
> >  ignite-spring-2.9.0-SNAPSHOT.jar
> >  lucene-analyzers-common-7.4.0.jar
> >  lucene-core-7.4.0.jar
> >  lucene-queryparser-7.4.0.jar
> >  spring-aop-4.3.18.RELEASE.jar
> >  spring-beans-4.3.18.RELEASE.jar
> >  spring-context-4.3.18.RELEASE.jar
> >  spring-core-4.3.18.RELEASE.jar
> >  spring-expression-4.3.18.RELEASE.jar
> >  spring-jdbc-4.3.18.RELEASE.jar
> >  spring-tx-4.3.18.RELEASE.jar
> > 
> >  Those are required for SQL and Spring configs to work properly,
> >  maybe we want to include them into the slim distro as well.
> > 
> >  On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> > >>> ilya.kasnach...@gmail.com
> > >
> >  wrote:
> > 
> > > Hello!
> > >
> > > This is a reasonable idea.
> > >
> > > I think we should also drop benchmarks/ directory from that build,
> > >> it's
> >  60M
> > > of (potentially vulnerable) JARs that are not needed by an average
> > > developer's use cases.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
> >  alexey.goncha...@gmail.com
> > >> :
> > >
> > >> Igniters,
> > >>
> > >> I would like to discuss with the community a possibility to create
> > >> additional 'slim' binary releases and docker images for Apache
> > >>> Ignite.
> > > The
> > >> reason is two-fold:
> > >> * The full set of 3rd party libraries distributed with Apache
> > >> Ignite
> > > looks
> > >> too large for me. I know there is an ongoing activity towards more
> >  clear
> > >> Ignite modularization [1][2][3], but this seems to be quite a long
> > > process.
> > >> On the other hand, creating a slim release may give an immediate
> >  benefit
> > > to
> > >> the users who are interested in a smaller image. For example,
> > >>> removing
> > > the
> > >> benchmarks alone from the binary release saves 80M.
> > >> * As Ilya Kasnacheev demonstrated [4], the more 3rd party
> > >> libraries
> > >>> we
> > >> have, the more potential vulnerabilities will show up in audit
> > >> tools.
> > > This
> > >> may be a formal barrier for Apache Ignite adoption and moving to
> > > production
> > >> for many users. Having a 

Re: Slim binary release and docker image for Apache Ignite

[Alexey Kuznetsov]

I'm +1 for "SLIM" it is a common name in Docker world.

On Wed, Jan 15, 2020 at 9:48 PM Petr Ivanov  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 
> 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 :
> >
> >> Alex,
> >>
> >> I'm on your end and support the proposal. Could you also clarify if you
> >> suggest we keeping or removing C++ and .NET thick clients?
> >>
> >> Speaking of the naming, how about titling such packages as 'core'
> instead
> >> of 'slim', i.e., 'apache-ignite-core-{version}'?
> >>
> >>
> >> -
> >> Denis
> >>
> >>
> >> On Wed, Jan 15, 2020 at 5:17 AM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> >>>
> >> wrote:
> >>
> >>> Hello!
> >>>
> >>> Pavel, I believe these JARs are fully covered by the list of modules
> >>> specified above.
> >>>
> >>> Regards,
> >>> --
> >>> Ilya Kasnacheev
> >>>
> >>>
> >>> ср, 15 янв. 2020 г. в 14:50, Pavel Tupitsyn :
> >>>
>  I like the idea, current distribution is certainly too big.
> 
>  Here is a list of jar files we include in NuGet package:
> 
>  cache-api-1.0.0.jar
>  commons-codec-1.11.jar
>  commons-logging-1.1.1.jar
>  h2-1.4.197.jar
>  ignite-core-2.9.0-SNAPSHOT.jar
>  ignite-indexing-2.9.0-SNAPSHOT.jar
>  ignite-shmem-1.0.0.jar
>  ignite-spring-2.9.0-SNAPSHOT.jar
>  lucene-analyzers-common-7.4.0.jar
>  lucene-core-7.4.0.jar
>  lucene-queryparser-7.4.0.jar
>  spring-aop-4.3.18.RELEASE.jar
>  spring-beans-4.3.18.RELEASE.jar
>  spring-context-4.3.18.RELEASE.jar
>  spring-core-4.3.18.RELEASE.jar
>  spring-expression-4.3.18.RELEASE.jar
>  spring-jdbc-4.3.18.RELEASE.jar
>  spring-tx-4.3.18.RELEASE.jar
> 
>  Those are required for SQL and Spring configs to work properly,
>  maybe we want to include them into the slim distro as well.
> 
>  On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> >>> ilya.kasnach...@gmail.com
> >
>  wrote:
> 
> > Hello!
> >
> > This is a reasonable idea.
> >
> > I think we should also drop benchmarks/ directory from that build,
> >> it's
>  60M
> > of (potentially vulnerable) JARs that are not needed by an average
> > developer's use cases.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
>  alexey.goncha...@gmail.com
> >> :
> >
> >> Igniters,
> >>
> >> I would like to discuss with the community a possibility to create
> >> additional 'slim' binary releases and docker images for Apache
> >>> Ignite.
> > The
> >> reason is two-fold:
> >> * The full set of 3rd party libraries distributed with Apache
> >> Ignite
> > looks
> >> too large for me. I know there is an ongoing activity towards more
>  clear
> >> Ignite modularization [1][2][3], but this seems to be quite a long
> > process.
> >> On the other hand, creating a slim release may give an immediate
>  benefit
> > to
> >> the users who are interested in a smaller image. For example,
> >>> removing
> > the
> >> benchmarks alone from the binary release saves 80M.
> >> * As Ilya Kasnacheev demonstrated [4], the more 3rd party
> >> libraries
> >>> we
> >> have, the more potential vulnerabilities will show up in audit
> >> tools.
> > This
> >> may be a formal barrier for Apache Ignite adoption and moving to
> > production
> >> for many users. Having a slim image with the minimum number of
> > dependencies
> >> (yet complete enough to fit the majority of use-cases)
> >> significantly
> >> reduces this risk.
> >>
> >> I wonder what community thinks regarding this idea? Given the
> >> recent
> > study
> >> of Apache Ignite use-cases, I suggest the following list of modules
> >>> to
>  be
> >> included to the slim release/image (a subject to discuss, of
> >> course):
> >> * ignite-core
> >> * ignite-indexing
> >> * ignite-rest-http
> >> * ignite-spring
> >> * ignite-log4j
> >> * ignite-log4j2
> >> * ignite-slf4j
> >> * ignite-urideploy
> >> * ignite-kubernetes
> >> * ignite-opencensus
> >>
> >> [1]
> >>
> >>
> >
> 

Re: Slim binary release and docker image for Apache Ignite

[Petr Ivanov]

+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  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 :
> 
>> 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 >> 
>> 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 :
>>> 
 I like the idea, current distribution is certainly too big.
 
 Here is a list of jar files we include in NuGet package:
 
 cache-api-1.0.0.jar
 commons-codec-1.11.jar
 commons-logging-1.1.1.jar
 h2-1.4.197.jar
 ignite-core-2.9.0-SNAPSHOT.jar
 ignite-indexing-2.9.0-SNAPSHOT.jar
 ignite-shmem-1.0.0.jar
 ignite-spring-2.9.0-SNAPSHOT.jar
 lucene-analyzers-common-7.4.0.jar
 lucene-core-7.4.0.jar
 lucene-queryparser-7.4.0.jar
 spring-aop-4.3.18.RELEASE.jar
 spring-beans-4.3.18.RELEASE.jar
 spring-context-4.3.18.RELEASE.jar
 spring-core-4.3.18.RELEASE.jar
 spring-expression-4.3.18.RELEASE.jar
 spring-jdbc-4.3.18.RELEASE.jar
 spring-tx-4.3.18.RELEASE.jar
 
 Those are required for SQL and Spring configs to work properly,
 maybe we want to include them into the slim distro as well.
 
 On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
>>> ilya.kasnach...@gmail.com
> 
 wrote:
 
> Hello!
> 
> This is a reasonable idea.
> 
> I think we should also drop benchmarks/ directory from that build,
>> it's
 60M
> of (potentially vulnerable) JARs that are not needed by an average
> developer's use cases.
> 
> Regards,
> --
> Ilya Kasnacheev
> 
> 
> ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
 alexey.goncha...@gmail.com
>> :
> 
>> Igniters,
>> 
>> I would like to discuss with the community a possibility to create
>> additional 'slim' binary releases and docker images for Apache
>>> Ignite.
> The
>> reason is two-fold:
>> * The full set of 3rd party libraries distributed with Apache
>> Ignite
> looks
>> too large for me. I know there is an ongoing activity towards more
 clear
>> Ignite modularization [1][2][3], but this seems to be quite a long
> process.
>> On the other hand, creating a slim release may give an immediate
 benefit
> to
>> the users who are interested in a smaller image. For example,
>>> removing
> the
>> benchmarks alone from the binary release saves 80M.
>> * As Ilya Kasnacheev demonstrated [4], the more 3rd party
>> libraries
>>> we
>> have, the more potential vulnerabilities will show up in audit
>> tools.
> This
>> may be a formal barrier for Apache Ignite adoption and moving to
> production
>> for many users. Having a slim image with the minimum number of
> dependencies
>> (yet complete enough to fit the majority of use-cases)
>> significantly
>> reduces this risk.
>> 
>> I wonder what community thinks regarding this idea? Given the
>> recent
> study
>> of Apache Ignite use-cases, I suggest the following list of modules
>>> to
 be
>> included to the slim release/image (a subject to discuss, of
>> course):
>> * ignite-core
>> * ignite-indexing
>> * ignite-rest-http
>> * ignite-spring
>> * ignite-log4j
>> * ignite-log4j2
>> * ignite-slf4j
>> * ignite-urideploy
>> * ignite-kubernetes
>> * ignite-opencensus
>> 
>> [1]
>> 
>> 
> 
 
>>> 
>> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html
>> [2]
>> 
>> 
> 
 
>>> 
>> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html
>> [3]
>> 
>> 
> 
 
>>> 
>> 

Re: Slim binary release and docker image for Apache Ignite

[Ilya Kasnacheev]

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 :

> 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  >
> 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 :
> >
> > > I like the idea, current distribution is certainly too big.
> > >
> > > Here is a list of jar files we include in NuGet package:
> > >
> > > cache-api-1.0.0.jar
> > > commons-codec-1.11.jar
> > > commons-logging-1.1.1.jar
> > > h2-1.4.197.jar
> > > ignite-core-2.9.0-SNAPSHOT.jar
> > > ignite-indexing-2.9.0-SNAPSHOT.jar
> > > ignite-shmem-1.0.0.jar
> > > ignite-spring-2.9.0-SNAPSHOT.jar
> > > lucene-analyzers-common-7.4.0.jar
> > > lucene-core-7.4.0.jar
> > > lucene-queryparser-7.4.0.jar
> > > spring-aop-4.3.18.RELEASE.jar
> > > spring-beans-4.3.18.RELEASE.jar
> > > spring-context-4.3.18.RELEASE.jar
> > > spring-core-4.3.18.RELEASE.jar
> > > spring-expression-4.3.18.RELEASE.jar
> > > spring-jdbc-4.3.18.RELEASE.jar
> > > spring-tx-4.3.18.RELEASE.jar
> > >
> > > Those are required for SQL and Spring configs to work properly,
> > > maybe we want to include them into the slim distro as well.
> > >
> > > On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello!
> > > >
> > > > This is a reasonable idea.
> > > >
> > > > I think we should also drop benchmarks/ directory from that build,
> it's
> > > 60M
> > > > of (potentially vulnerable) JARs that are not needed by an average
> > > > developer's use cases.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > >
> > > > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com
> > > > >:
> > > >
> > > > > Igniters,
> > > > >
> > > > > I would like to discuss with the community a possibility to create
> > > > > additional 'slim' binary releases and docker images for Apache
> > Ignite.
> > > > The
> > > > > reason is two-fold:
> > > > >  * The full set of 3rd party libraries distributed with Apache
> Ignite
> > > > looks
> > > > > too large for me. I know there is an ongoing activity towards more
> > > clear
> > > > > Ignite modularization [1][2][3], but this seems to be quite a long
> > > > process.
> > > > > On the other hand, creating a slim release may give an immediate
> > > benefit
> > > > to
> > > > > the users who are interested in a smaller image. For example,
> > removing
> > > > the
> > > > > benchmarks alone from the binary release saves 80M.
> > > > >  * As Ilya Kasnacheev demonstrated [4], the more 3rd party
> libraries
> > we
> > > > > have, the more potential vulnerabilities will show up in audit
> tools.
> > > > This
> > > > > may be a formal barrier for Apache Ignite adoption and moving to
> > > > production
> > > > > for many users. Having a slim image with the minimum number of
> > > > dependencies
> > > > > (yet complete enough to fit the majority of use-cases)
> significantly
> > > > > reduces this risk.
> > > > >
> > > > > I wonder what community thinks regarding this idea? Given the
> recent
> > > > study
> > > > > of Apache Ignite use-cases, I suggest the following list of modules
> > to
> > > be
> > > > > included to the slim release/image (a subject to discuss, of
> course):
> > > > >  * ignite-core
> > > > >  * ignite-indexing
> > > > >  * ignite-rest-http
> > > > >  * ignite-spring
> > > > >  * ignite-log4j
> > > > >  * ignite-log4j2
> > > > >  * ignite-slf4j
> > > > >  * ignite-urideploy
> > > > >  * ignite-kubernetes
> > > > >  * ignite-opencensus
> > > > >
> > > > > [1]
> > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html
> > > > > [2]
> > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html
> > > > > [3]
> > > > >
> > > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html
> > > > > [4]
> > > > >
> > > > >
> > > >
> > >

Re: Slim binary release and docker image for Apache Ignite

[Denis Magda]

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 
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 :
>
> > I like the idea, current distribution is certainly too big.
> >
> > Here is a list of jar files we include in NuGet package:
> >
> > cache-api-1.0.0.jar
> > commons-codec-1.11.jar
> > commons-logging-1.1.1.jar
> > h2-1.4.197.jar
> > ignite-core-2.9.0-SNAPSHOT.jar
> > ignite-indexing-2.9.0-SNAPSHOT.jar
> > ignite-shmem-1.0.0.jar
> > ignite-spring-2.9.0-SNAPSHOT.jar
> > lucene-analyzers-common-7.4.0.jar
> > lucene-core-7.4.0.jar
> > lucene-queryparser-7.4.0.jar
> > spring-aop-4.3.18.RELEASE.jar
> > spring-beans-4.3.18.RELEASE.jar
> > spring-context-4.3.18.RELEASE.jar
> > spring-core-4.3.18.RELEASE.jar
> > spring-expression-4.3.18.RELEASE.jar
> > spring-jdbc-4.3.18.RELEASE.jar
> > spring-tx-4.3.18.RELEASE.jar
> >
> > Those are required for SQL and Spring configs to work properly,
> > maybe we want to include them into the slim distro as well.
> >
> > On Wed, Jan 15, 2020 at 2:25 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> > >
> > wrote:
> >
> > > Hello!
> > >
> > > This is a reasonable idea.
> > >
> > > I think we should also drop benchmarks/ directory from that build, it's
> > 60M
> > > of (potentially vulnerable) JARs that are not needed by an average
> > > developer's use cases.
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > >:
> > >
> > > > Igniters,
> > > >
> > > > I would like to discuss with the community a possibility to create
> > > > additional 'slim' binary releases and docker images for Apache
> Ignite.
> > > The
> > > > reason is two-fold:
> > > >  * The full set of 3rd party libraries distributed with Apache Ignite
> > > looks
> > > > too large for me. I know there is an ongoing activity towards more
> > clear
> > > > Ignite modularization [1][2][3], but this seems to be quite a long
> > > process.
> > > > On the other hand, creating a slim release may give an immediate
> > benefit
> > > to
> > > > the users who are interested in a smaller image. For example,
> removing
> > > the
> > > > benchmarks alone from the binary release saves 80M.
> > > >  * As Ilya Kasnacheev demonstrated [4], the more 3rd party libraries
> we
> > > > have, the more potential vulnerabilities will show up in audit tools.
> > > This
> > > > may be a formal barrier for Apache Ignite adoption and moving to
> > > production
> > > > for many users. Having a slim image with the minimum number of
> > > dependencies
> > > > (yet complete enough to fit the majority of use-cases) significantly
> > > > reduces this risk.
> > > >
> > > > I wonder what community thinks regarding this idea? Given the recent
> > > study
> > > > of Apache Ignite use-cases, I suggest the following list of modules
> to
> > be
> > > > included to the slim release/image (a subject to discuss, of course):
> > > >  * ignite-core
> > > >  * ignite-indexing
> > > >  * ignite-rest-http
> > > >  * ignite-spring
> > > >  * ignite-log4j
> > > >  * ignite-log4j2
> > > >  * ignite-slf4j
> > > >  * ignite-urideploy
> > > >  * ignite-kubernetes
> > > >  * ignite-opencensus
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html
> > > > [2]
> > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html
> > > > [3]
> > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html
> > > > [4]
> > > >
> > > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-td43616i100.html#a44994
> > > >
> > > > --AG
> > > >
> > >
> >
>

Re: Slim binary release and docker image for Apache Ignite

[Ilya Kasnacheev]

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 :

> 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  >
> wrote:
>
> > Hello!
> >
> > This is a reasonable idea.
> >
> > I think we should also drop benchmarks/ directory from that build, it's
> 60M
> > of (potentially vulnerable) JARs that are not needed by an average
> > developer's use cases.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 15 янв. 2020 г. в 13:10, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> > > Igniters,
> > >
> > > I would like to discuss with the community a possibility to create
> > > additional 'slim' binary releases and docker images for Apache Ignite.
> > The
> > > reason is two-fold:
> > >  * The full set of 3rd party libraries distributed with Apache Ignite
> > looks
> > > too large for me. I know there is an ongoing activity towards more
> clear
> > > Ignite modularization [1][2][3], but this seems to be quite a long
> > process.
> > > On the other hand, creating a slim release may give an immediate
> benefit
> > to
> > > the users who are interested in a smaller image. For example, removing
> > the
> > > benchmarks alone from the binary release saves 80M.
> > >  * As Ilya Kasnacheev demonstrated [4], the more 3rd party libraries we
> > > have, the more potential vulnerabilities will show up in audit tools.
> > This
> > > may be a formal barrier for Apache Ignite adoption and moving to
> > production
> > > for many users. Having a slim image with the minimum number of
> > dependencies
> > > (yet complete enough to fit the majority of use-cases) significantly
> > > reduces this risk.
> > >
> > > I wonder what community thinks regarding this idea? Given the recent
> > study
> > > of Apache Ignite use-cases, I suggest the following list of modules to
> be
> > > included to the slim release/image (a subject to discuss, of course):
> > >  * ignite-core
> > >  * ignite-indexing
> > >  * ignite-rest-http
> > >  * ignite-spring
> > >  * ignite-log4j
> > >  * ignite-log4j2
> > >  * ignite-slf4j
> > >  * ignite-urideploy
> > >  * ignite-kubernetes
> > >  * ignite-opencensus
> > >
> > > [1]
> > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Ignite-3-0-and-to-be-removed-list-td42330.html
> > > [2]
> > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12358-Migrate-ZeroMQ-module-to-ignite-extensions-td45067.html
> > > [3]
> > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-12361-Migrate-Flume-module-to-ignite-extensions-td45010.html
> > > [4]
> > >
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-td43616i100.html#a44994
> > >
> > > --AG
> > >
> >
>

Re: Slim binary release and docker image for Apache Ignite

[Ilya Kasnacheev]

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 :

> 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
>

Slim binary release and docker image for Apache Ignite

[Alexey Goncharuk]

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: IGNITE-12018 Web Agent docker image: 'functions.sh' not found

[Saikat Maitra]

Hi Andrey,

Thank you for review and approving my request.

As discussed I also validated the apache-ignite docker image and I am
getting different error as mentioned below.

Step 5/11 : COPY apache-ignite* apache-ignite
COPY failed: no source files were specified

I will look into apache-ignite docker image issue further.

Regards
Saikat

On Sun, Sep 1, 2019 at 9:32 PM Andrey Novikov  wrote:

> Looks like same logic is used for apache-ignite docker image. I approved
> your PR
>
>
> On Mon, Sep 2, 2019 at 3:22 AM Saikat Maitra 
> wrote:
> >
> > Hi,
> >
> > This is a tiny PR. Please take a look and let me know if it is ok to
> merge.
> >
> > I have validated the results locally and it is working as expected.
> >
> > Regards,
> > Saikat
> >
> > On Sun, Aug 25, 2019 at 3:24 PM Saikat Maitra 
> > wrote:
> >
> > > Hello,
> > >
> > > I have raised PR for the following issue
> > >
> > > IGNITE-12018 Web Agent docker image: 'functions.sh' not found
> > >
> > > Jira issue : https://issues.apache.org/jira/browse/IGNITE-12018
> > >
> > > PR : https://github.com/apache/ignite/pull/6808
> > >
> > > Please review and share feedback.
> > >
> > > Regards,
> > > Saikat
> > >
> > >
> > >
>

Re: IGNITE-12018 Web Agent docker image: 'functions.sh' not found

[Andrey Novikov]

Looks like same logic is used for apache-ignite docker image. I approved your PR


On Mon, Sep 2, 2019 at 3:22 AM Saikat Maitra  wrote:
>
> Hi,
>
> This is a tiny PR. Please take a look and let me know if it is ok to merge.
>
> I have validated the results locally and it is working as expected.
>
> Regards,
> Saikat
>
> On Sun, Aug 25, 2019 at 3:24 PM Saikat Maitra 
> wrote:
>
> > Hello,
> >
> > I have raised PR for the following issue
> >
> > IGNITE-12018 Web Agent docker image: 'functions.sh' not found
> >
> > Jira issue : https://issues.apache.org/jira/browse/IGNITE-12018
> >
> > PR : https://github.com/apache/ignite/pull/6808
> >
> > Please review and share feedback.
> >
> > Regards,
> > Saikat
> >
> >
> >

Re: IGNITE-12018 Web Agent docker image: 'functions.sh' not found

[Saikat Maitra]

Hi,

This is a tiny PR. Please take a look and let me know if it is ok to merge.

I have validated the results locally and it is working as expected.

Regards,
Saikat

On Sun, Aug 25, 2019 at 3:24 PM Saikat Maitra 
wrote:

> Hello,
>
> I have raised PR for the following issue
>
> IGNITE-12018 Web Agent docker image: 'functions.sh' not found
>
> Jira issue : https://issues.apache.org/jira/browse/IGNITE-12018
>
> PR : https://github.com/apache/ignite/pull/6808
>
> Please review and share feedback.
>
> Regards,
> Saikat
>
>
>

IGNITE-12018 Web Agent docker image: 'functions.sh' not found

[Saikat Maitra]

Hello,

I have raised PR for the following issue

IGNITE-12018 Web Agent docker image: 'functions.sh' not found

Jira issue : https://issues.apache.org/jira/browse/IGNITE-12018

PR : https://github.com/apache/ignite/pull/6808

Please review and share feedback.

Regards,
Saikat

[jira] [Created] (IGNITE-12018) Web Agent docker image: 'functions.sh' not found

[Igor Belyakov (JIRA)]

Igor Belyakov created IGNITE-12018:
--

 Summary: Web Agent docker image: 'functions.sh' not found
 Key: IGNITE-12018
 URL: https://issues.apache.org/jira/browse/IGNITE-12018
 Project: Ignite
  Issue Type: Bug
  Components: UI
Affects Versions: 2.7.5, 2.7
Reporter: Igor Belyakov


Steps to reproduce:

1. Build docker image by using "docker/web-agent/Dockerfile" according to 
README file.
2. Start docker container by using generated image.
3. Next error happens on container start:

 
{code:java}
./ignite-web-agent.sh: line 39: 
/opt/ignite/ignite-web-agent/include/functions.sh: No such file or directory
./ignite-web-agent.sh: line 44: checkJava: command not found
./ignite-web-agent.sh: line 64: javaMajorVersion: command not found
./ignite-web-agent.sh: line 66: [: -eq: unary operator expected
./ignite-web-agent.sh: line 71: [: -gt: unary operator expected
./ignite-web-agent.sh: line 84: [: -eq: unary operator expected
./ignite-web-agent.sh: line 95: : command not found{code}
 

Image contains next files in "/opt/ignite/ignite-web-agent" directory without 
any sub directories:

 
{code:java}
-rw-r--r-- 1 root root 89 Dec 4 2018 README.txt
-rw-r--r-- 1 root root 8080 Dec 4 2018 db-init.sql
-rw-rw-r-- 1 root root 203 Jul 25 12:30 default.properties
-rwxr-xr-x 1 root root 2721 Dec 4 2018 functions.sh
-rw-r--r-- 1 root root 29118502 Dec 6 2018 ignite-web-agent-2.7.0.jar
-rw-r--r-- 1 root root 4590 Dec 4 2018 ignite-web-agent.bat
-rw-rw-r-- 1 root root 561 Jul 25 16:31 ignite-web-agent.log
-rwxr-xr-x 1 root root 3229 Jul 25 16:33 ignite-web-agent.sh 
{code}
The issue happens during executing files copy command in Dockerfile, it doesn't 
keep directories structure. To solve this problem "COPY ignite-web-agent*/* ./" 
command should be changed to "COPY ignite-web-agent* ./"



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (IGNITE-12007) Latest "apacheignite/web-console-backend" docker image is broken

[Igor Belyakov (JIRA)]

Igor Belyakov created IGNITE-12007:
--

 Summary: Latest "apacheignite/web-console-backend" docker image is 
broken
 Key: IGNITE-12007
 URL: https://issues.apache.org/jira/browse/IGNITE-12007
 Project: Ignite
  Issue Type: Bug
  Components: UI
Affects Versions: 2.7
Reporter: Igor Belyakov


It's not possible to run docker container by using the latest version of 
"apacheignite/web-console-backend" image.

Next error happens on the start:
{code:java}
npm ERR! A complete log of this run can be found in:
npm ERR! /root/.npm/_logs/2019-07-23T14_24_40_353Z-debug.log
npm ERR! path /opt/web-console/package.json
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall open
npm ERR! enoent ENOENT: no such file or directory, open 
'/opt/web-console/package.json'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent{code}
How to reproduce:

Run container by using docker-compose as described here: 
[https://hub.docker.com/r/apacheignite/web-console-backend]

 

Seems like it was broken by the next commit:

[https://github.com/apache/ignite/commit/4c295f8f468ddfce458948c17c13b1748b13e918#diff-ec0d595d738c4207e08ce210624e902aR22]



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (IGNITE-10889) Web Console should work with Web Agent started from Docker image.

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-10889:
-

 Summary: Web Console should work with Web Agent started from 
Docker image.
 Key: IGNITE-10889
 URL: https://issues.apache.org/jira/browse/IGNITE-10889
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Alexey Kuznetsov






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-10121) Web console: Create documentation how to run Web agent as Docker image

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-10121:
--

 Summary: Web console: Create documentation how to run Web agent as 
Docker image
 Key: IGNITE-10121
 URL: https://issues.apache.org/jira/browse/IGNITE-10121
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Vasiliy Sisko
Assignee: Ilya Murchenko


Especially specify ho configure path to external folder with jdbc driver.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4038: IGNITE-8526 Create web-agent docker image for k8s...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4038


---

[jira] [Created] (IGNITE-8932) Docker image: doesn't handle SIGTERM

[Ivan Yani (JIRA)]

Ivan Yani created IGNITE-8932:
-

 Summary: Docker image: doesn't handle SIGTERM
 Key: IGNITE-8932
 URL: https://issues.apache.org/jira/browse/IGNITE-8932
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Yani


So there's this "pid 1" issue with ignite image published on docker hub. The 
problem manifests in not being able to send SIGTERM to ignite java process.

The reason of this issue is that the signal is sent to the shell script which 
start ignite, not ignite itself. To fix the issue you need to use "exec" in 
bash script to replace bash process with java process.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #4038: IGNITE-8526 Create web-agent docker image for k8s...

[vveider]

GitHub user vveider opened a pull request:

https://github.com/apache/ignite/pull/4038

IGNITE-8526 Create web-agent docker image for k8s deployment

 * added web-agent separate docker image build
 * refactored and unified docker specifications layout

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-8526

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4038.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #4038


commit e6cc97a7592f1d5065e6f40dc0c96fc70018039f
Author: Ivanov Petr <pivanov@...>
Date:   2018-05-21T14:11:05Z

IGNITE-8526 Create web-agent docker image for k8s deployment
 * added web-agent separate docker image build
 * refactored and unified docker specifications layout




---

[jira] [Created] (IGNITE-8526) Create web-agent docker image for k8s deployment

[Roman Guseinov (JIRA)]

Roman Guseinov created IGNITE-8526:
--

 Summary: Create web-agent docker image for k8s deployment
 Key: IGNITE-8526
 URL: https://issues.apache.org/jira/browse/IGNITE-8526
 Project: Ignite
  Issue Type: Improvement
  Components: UI
Reporter: Roman Guseinov
Assignee: Peter Ivanov
 Attachments: Dockerfile

Currently, apacheignite/web-console-standalone is not enough to run web-console 
in Kubernetes environment. The only way to connect a cluster from web console 
is to use web-agent. That's why we need a docker image which we can configure 
(grid and console addresses, security tokens) and run on k8s env.

Dockerfile example is attached.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8281) Add Docker image build for Apache Ignite Release

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-8281:


 Summary: Add Docker image build for Apache Ignite Release
 Key: IGNITE-8281
 URL: https://issues.apache.org/jira/browse/IGNITE-8281
 Project: Ignite
  Issue Type: Task
Reporter: Peter Ivanov
Assignee: Peter Ivanov


Similar to Apache Ignite Nightly Release, add Docker images (Apache Ignite and 
WebConsole) build to Apache Ignite Release build. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-8222) Add docker image build for Nightly Release

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-8222:


 Summary: Add docker image build for Nightly Release
 Key: IGNITE-8222
 URL: https://issues.apache.org/jira/browse/IGNITE-8222
 Project: Ignite
  Issue Type: New Feature
Reporter: Peter Ivanov
Assignee: Peter Ivanov


# Create Meta-runner for Docker images building in TeamCity.
# Add new build on TeamCity which will build docker image from master.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: ignite 2.3.0 docker image contains 2.2.0 files.

[Nikolai Tikhonov]

Good catch, thank you!

The latest image contains 2.3.0 (docker pull apacheignite/ignite) but image
with 2.3.0 tag contains binary files for 2.2.0 version. I've fixed it.

On Fri, Nov 3, 2017 at 8:13 AM, Denis Magda <dma...@apache.org> wrote:

> Nick, Vovan,
>
> Have we really upgraded docker and the other images to 2.3?
>
> —
> Denis
>
> Begin forwarded message:
>
> *From: *bjason <bjason...@gmail.com>
> *Subject: **ignite 2.3.0 docker image contains 2.2.0 files.*
> *Date: *November 2, 2017 at 3:37:34 PM PDT
> *To: *u...@ignite.apache.org
> *Reply-To: *u...@ignite.apache.org
>
>
>
> ignite 2.3.0 docker image contains 2.2.0 files. Please check.
>
> $ docker pull apacheignite/ignite:2.3.0
> 2.3.0: Pulling from apacheignite/ignite
> 3e17c6eae66c: Pull complete
> 74d44b20f851: Pull complete
> a156217f3fa4: Pull complete
> 4a1ed13b6faa: Pull complete
> 77980e5d0a6d: Pull complete
> 5458607a81d3: Pull complete
> e34cf8338f42: Pull complete
> 2f3d3da5c56e: Pull complete
> 2ade7a861e3f: Pull complete
> 686e6ce078d5: Pull complete
> f1d36075868f: Pull complete
> 2131367cd2fc: Pull complete
> 4c80ef6fe713: Pull complete
> ebe7c3987073: Pull complete
> Digest:
> sha256:78c6cca73d8a360d4705a8dbe722f386b90cdf6115a247c59753b796254a9116
> Status: Downloaded newer image for apacheignite/ignite:2.3.0
>
> $ sudo docker run -it --net=host -e
> "CONFIG_URI=https://raw.githubusercontent.com/apache/
> ignite/master/examples/config/example-cache.xml"
> apacheignite/ignite:2.3.0
> /opt/ignite/*apache-ignite-fabric-2.2.0-bin*/bin/ignite.sh, WARN: Failed
> to
> resolve JMX host (JMX will be disabled): moby
> [22:09:46]__  
> [22:09:46]   /  _/ ___/ |/ /  _/_  __/ __/
> [22:09:46]  _/ // (7 7// /  / / / _/
> [22:09:46] /___/\___/_/|_/___/ /_/ /___/
>
>
> $ docker ps
> CONTAINER IDIMAGE   COMMAND
> CREATED STATUS  PORTS   NAMES
> db37561bc87eapacheignite/ignite:2.3.0   "/bin/sh -c $IGNIT..."
>   22
> seconds ago  Up 20 seconds   sleepy_panini
>
> $ docker exec -it sudo docker run -it --net=host -e
> "CONFIG_URI=https://raw.githubusercontent.com/apache/
> ignite/master/examples/config/example-cache.xml"
> apacheignite/ignite
> $ docker exec -it db37561bc87e bash
>
> root@moby:/opt/ignite# ls -l
> total 4
> drwxr-xr-x 1 root root 4096 Nov  2 22:09 *apache-ignite-fabric-2.2.0-bin*
> root@moby:/opt/ignite#
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>
>
>

[jira] [Created] (IGNITE-5508) Document Web Console Installation from Docker Image

[Denis Magda (JIRA)]

Denis Magda created IGNITE-5508:
---

 Summary: Document Web Console Installation from Docker Image
 Key: IGNITE-5508
 URL: https://issues.apache.org/jira/browse/IGNITE-5508
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Magda
Assignee: Alexey Kuznetsov
 Fix For: 2.1


We need to add a section to the very beginning of the doc below explaining how 
to install and set up the console from the Docker image:
https://apacheignite-tools.readme.io/docs/build-and-deploy





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

IGNITE-2377 Docker image hangs on Mac OS

[chandresh pancholi]

I have verified on OS X Yosemite (V 10.10.5) with docker 1.12 with ignite
1.7 and it worked fine.
It would be great if someone verifies it also.


Thanks

-- 
Chandresh Pancholi
Senior Software Engineer
Flipkart.com
Email-id:chandresh.panch...@flipkart.com
Contact:08951803660

[GitHub] ignite pull request #757: Docker image for Ignite 1.6.0

[zshamrock]

Github user zshamrock closed the pull request at:

https://github.com/apache/ignite/pull/757


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Docker image for Ignite 1.6.0 release pull request

[Nikolay Tikhonov]

Hi Aliaksandr!

I've reviewed and merge your changes to master.

Thank you for your contribution!

On Tue, Jun 7, 2016 at 5:31 PM, Denis Magda <dma...@gridgain.com> wrote:

> Nikolay,
>
> As a maintainer of this component please do the review.
>
> —
> Denis
>
> > On Jun 5, 2016, at 3:18 PM, zshamrock <aliaksandr.kaz...@gmail.com>
> wrote:
> >
> > Hi, guys, what about the following
> https://github.com/apache/ignite/pull/757?
> >
> > Is already someone from DataGrid/Ignite working on official docker image
> for
> > 1.6.0 release, or you can take a look into the pull request above I've
> > submitted.
> >
> >
> >
> >
> > --
> > View this message in context:
> http://apache-ignite-developers.2346864.n4.nabble.com/Docker-image-for-Ignite-1-6-0-release-pull-request-tp9276.html
> > Sent from the Apache Ignite Developers mailing list archive at
> Nabble.com.
>
>

Re: Docker image for Ignite 1.6.0 release pull request

[Denis Magda]

Nikolay,

As a maintainer of this component please do the review.

—
Denis

> On Jun 5, 2016, at 3:18 PM, zshamrock <aliaksandr.kaz...@gmail.com> wrote:
> 
> Hi, guys, what about the following https://github.com/apache/ignite/pull/757?
> 
> Is already someone from DataGrid/Ignite working on official docker image for
> 1.6.0 release, or you can take a look into the pull request above I've
> submitted.
> 
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Docker-image-for-Ignite-1-6-0-release-pull-request-tp9276.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: Docker image for Ignite 1.6.0 release pull request

[zshamrock]

Updated Dockerfile/PR - reduce the generated Docker image size from 1.061GB
to 885MB.



--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Docker-image-for-Ignite-1-6-0-release-pull-request-tp9276p9282.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Docker image for Ignite 1.6.0 release pull request

[zshamrock]

Hi, guys, what about the following https://github.com/apache/ignite/pull/757?

Is already someone from DataGrid/Ignite working on official docker image for
1.6.0 release, or you can take a look into the pull request above I've
submitted.




--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Docker-image-for-Ignite-1-6-0-release-pull-request-tp9276.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

[GitHub] ignite pull request: Docker image for Ignite 1.6.0

[zshamrock]

GitHub user zshamrock opened a pull request:

https://github.com/apache/ignite/pull/757

Docker image for Ignite 1.6.0



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/zshamrock/ignite master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/757.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #757


commit 704a15adcf236e4eca842d1a677cacaf1bdd56dd
Author: Aliaksandr Kazlou <aliaksandr.kaz...@gmail.com>
Date:   2016-05-25T23:34:21Z

Docker image for Ignite 1.6.0




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Docker image

[Nikolay Tikhonov]

Val,

Our docker repo contains not only the latest version or 1.0.0-incubating,
there all versions.  List of versions here [1]. I've updated "Dockerfile"
tab, now it shows dockerfile from "1.5.0.final" tag.

[1] https://hub.docker.com/r/apacheignite/ignite/tags

On Fri, Jan 29, 2016 at 9:34 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Nikolay,
>
> As far as I know you were creating Docker images for Ignite.
>
> I just opened it [1] and noticed that the version is 1.0.0 there. Is there
> a reason for this? Can we switch it to the latest?
>
> [1] https://hub.docker.com/r/apacheignite/ignite/~/dockerfile/
>
> -Val
>

Re: Docker image

[Valentin Kulichenko]

Thanks, Nikolay!

On Fri, Jan 29, 2016 at 12:43 AM, Nikolay Tikhonov 
wrote:

> Val,
>
> Our docker repo contains not only the latest version or 1.0.0-incubating,
> there all versions.  List of versions here [1]. I've updated "Dockerfile"
> tab, now it shows dockerfile from "1.5.0.final" tag.
>
> [1] https://hub.docker.com/r/apacheignite/ignite/tags
>
> On Fri, Jan 29, 2016 at 9:34 AM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Nikolay,
> >
> > As far as I know you were creating Docker images for Ignite.
> >
> > I just opened it [1] and noticed that the version is 1.0.0 there. Is
> there
> > a reason for this? Can we switch it to the latest?
> >
> > [1] https://hub.docker.com/r/apacheignite/ignite/~/dockerfile/
> >
> > -Val
> >
>

Docker image

[Valentin Kulichenko]

Nikolay,

As far as I know you were creating Docker images for Ignite.

I just opened it [1] and noticed that the version is 1.0.0 there. Is there
a reason for this? Can we switch it to the latest?

[1] https://hub.docker.com/r/apacheignite/ignite/~/dockerfile/

-Val

Re: Ignite docker image

[Nikolay Tikhonov]

Dima,

Docker hub repository has six images. Each image is labeled with tag
(1.0.0-incubating, 1.1.0-incubating, 1.2.0-incubating and etc) [1] and
stores specific ignite distributive i.e. image with tag 1.0.0-incubating
stores Ignite 1.0.0-incubating distributive, 1.1.0-incubating stores Ignite
1.1.0-incubating and etc. For downloading docker image with specific
version need to perform docker pull and specify the tag. For example:
docker pull apacheignite/ignite:1.4.0 (1.4.0 is tag) download image with
Ignite 1.4.0 distributive. Whenever tag is not specific (docker pull
apacheignite/ignite is the same docker pull apacheignite/ignite:latest)
will download image with latest tag, right now latest tag contains Apache
Ignite 1.5 distributive.

https://hub.docker.com/r/apacheignite/ignite/tags/

On Mon, Jan 11, 2016 at 9:55 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:

> Nick,
>
> I am still a bit confused. Can you please describe what happens right now
> with the image we have stored on the docker hub? I am interested in what
> Ignite version is stored there and what Ignite version is downloaded
> whenever no specific version is passed.
>
> D.
>
> On Mon, Jan 11, 2016 at 10:26 AM, Nikolay Tikhonov <ntikho...@gridgain.com
> >
> wrote:
>
> > >
> > > In that case, why does the docker image contain any version of Ignite
> at
> > > all?
> > >
> > We download docker image which was built from Dockerfile (which contains
> > specific version of Ignite) and the image contains Ignite distributive.
> > Apache Ignite distributive is downloaded only once in during the build of
> > the docker image.
> >
>

Re: Ignite docker image

[Dmitriy Setrakyan]

Nick,

Any chance we can update the dockerfile to work the latest release?
https://hub.docker.com/r/apacheignite/ignite/~/dockerfile/

D.

On Tue, Jan 12, 2016 at 4:08 AM, Nikolay Tikhonov <ntikho...@gridgain.com>
wrote:

> Dima,
>
> Docker hub repository has six images. Each image is labeled with tag
> (1.0.0-incubating, 1.1.0-incubating, 1.2.0-incubating and etc) [1] and
> stores specific ignite distributive i.e. image with tag 1.0.0-incubating
> stores Ignite 1.0.0-incubating distributive, 1.1.0-incubating stores Ignite
> 1.1.0-incubating and etc. For downloading docker image with specific
> version need to perform docker pull and specify the tag. For example:
> docker pull apacheignite/ignite:1.4.0 (1.4.0 is tag) download image with
> Ignite 1.4.0 distributive. Whenever tag is not specific (docker pull
> apacheignite/ignite is the same docker pull apacheignite/ignite:latest)
> will download image with latest tag, right now latest tag contains Apache
> Ignite 1.5 distributive.
>
> https://hub.docker.com/r/apacheignite/ignite/tags/
>
> On Mon, Jan 11, 2016 at 9:55 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
> wrote:
>
> > Nick,
> >
> > I am still a bit confused. Can you please describe what happens right now
> > with the image we have stored on the docker hub? I am interested in what
> > Ignite version is stored there and what Ignite version is downloaded
> > whenever no specific version is passed.
> >
> > D.
> >
> > On Mon, Jan 11, 2016 at 10:26 AM, Nikolay Tikhonov <
> ntikho...@gridgain.com
> > >
> > wrote:
> >
> > > >
> > > > In that case, why does the docker image contain any version of Ignite
> > at
> > > > all?
> > > >
> > > We download docker image which was built from Dockerfile (which
> contains
> > > specific version of Ignite) and the image contains Ignite distributive.
> > > Apache Ignite distributive is downloaded only once in during the build
> of
> > > the docker image.
> > >
> >
>

Re: Ignite docker image

[Nikolay Tikhonov]

Dima,
Docker hub shows Dockerfile for `1.0.0-incubating` tag [1]. For this tag it
is correct. [2]
I would prefer see Dockerfile for the latest version, but I can't find
functionality to change it. I'll ask DockerHub community how fix it.

1. https://hub.docker.com/r/apacheignite/ignite/~/dockerfile/
2.
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=tree;f=modules/docker;h=7406e8b30a8ec6c2cdf9974c4a4e41c3df838bbf;hb=HEAD

On Mon, Jan 4, 2016 at 9:17 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:

> Gents,
>
> I just looked at the Ignite docker image [1] and it has the following
> directive in it:
>
> *ENV IGNITE_HOME /opt/ignite/ignite-fabric-1.0.0-incubating*
>
> Looked like it needs some freshening up.
>
> Nick, given that you have been managing this docker account, can you please
> update it?
>
> D.
>

Re: Ignite docker image

[Dmitriy Setrakyan]

Nick,

I am not sure I understand. Are you suggesting we have different docker
files for different versions? I would prefer that unless a version is
explicitly specified, the docker file should download the latest version.
Can we update the file on ignite docker hub?

D.

On Mon, Jan 11, 2016 at 7:10 AM, Nikolay Tikhonov <ntikho...@gridgain.com>
wrote:

> Dima,
> Docker hub shows Dockerfile for `1.0.0-incubating` tag [1]. For this tag it
> is correct. [2]
> I would prefer see Dockerfile for the latest version, but I can't find
> functionality to change it. I'll ask DockerHub community how fix it.
>
> 1. https://hub.docker.com/r/apacheignite/ignite/~/dockerfile/
> 2.
>
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=tree;f=modules/docker;h=7406e8b30a8ec6c2cdf9974c4a4e41c3df838bbf;hb=HEAD
>
> On Mon, Jan 4, 2016 at 9:17 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
> wrote:
>
> > Gents,
> >
> > I just looked at the Ignite docker image [1] and it has the following
> > directive in it:
> >
> > *ENV IGNITE_HOME /opt/ignite/ignite-fabric-1.0.0-incubating*
> >
> > Looked like it needs some freshening up.
> >
> > Nick, given that you have been managing this docker account, can you
> please
> > update it?
> >
> > D.
> >
>

Re: Ignite docker image

[Nikolay Tikhonov]

On Mon, Jan 11, 2016 at 8:39 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:
>
>
> I am not sure I understand. Are you suggesting we have different docker
> files for different versions?


Yes, for each Ignite version need to create Dockerfile with version and tag
on DockerHub.

I would prefer that unless a version is explicitly specified, the docker
> file should download the latest version.
>

Docker image contains a specific version of Ignite. Apache Ignite docker
repo contains the following tags [1] that essentially means exist six
docker images and each contains own version Ignite. For example if user
perform *docker pull apacheignite/ignite:1.4.0 *command then will be
downloaded image with Ignite version 1.4.0. If user doesn't set version
explicitly (*docker pull apacheignite/ignite*) then will be downloaded
image with the latest ignite version.

1. https://hub.docker.com/r/apacheignite/ignite/tags/

Re: Ignite docker image

[Dmitriy Setrakyan]

Nick,

I am still a bit confused. Can you please describe what happens right now
with the image we have stored on the docker hub? I am interested in what
Ignite version is stored there and what Ignite version is downloaded
whenever no specific version is passed.

D.

On Mon, Jan 11, 2016 at 10:26 AM, Nikolay Tikhonov <ntikho...@gridgain.com>
wrote:

> >
> > In that case, why does the docker image contain any version of Ignite at
> > all?
> >
> We download docker image which was built from Dockerfile (which contains
> specific version of Ignite) and the image contains Ignite distributive.
> Apache Ignite distributive is downloaded only once in during the build of
> the docker image.
>

Re: Ignite docker image

[Dmitriy Setrakyan]

Nick,

It sounds like we always download a version of ignite, either latest or
provided by user. In that case, why does the docker image contain any
version of Ignite at all?

D.

On Mon, Jan 11, 2016 at 10:08 AM, Nikolay Tikhonov <ntikho...@gridgain.com>
wrote:

> On Mon, Jan 11, 2016 at 8:39 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
> wrote:
> >
> >
> > I am not sure I understand. Are you suggesting we have different docker
> > files for different versions?
>
>
> Yes, for each Ignite version need to create Dockerfile with version and tag
> on DockerHub.
>
> I would prefer that unless a version is explicitly specified, the docker
> > file should download the latest version.
> >
>
> Docker image contains a specific version of Ignite. Apache Ignite docker
> repo contains the following tags [1] that essentially means exist six
> docker images and each contains own version Ignite. For example if user
> perform *docker pull apacheignite/ignite:1.4.0 *command then will be
> downloaded image with Ignite version 1.4.0. If user doesn't set version
> explicitly (*docker pull apacheignite/ignite*) then will be downloaded
> image with the latest ignite version.
>
> 1. https://hub.docker.com/r/apacheignite/ignite/tags/
>

Re: Ignite docker image

[Nikolay Tikhonov]

>
> In that case, why does the docker image contain any version of Ignite at
> all?
>
We download docker image which was built from Dockerfile (which contains
specific version of Ignite) and the image contains Ignite distributive.
Apache Ignite distributive is downloaded only once in during the build of
the docker image.

Ignite docker image

[Dmitriy Setrakyan]

Gents,

I just looked at the Ignite docker image [1] and it has the following
directive in it:

*ENV IGNITE_HOME /opt/ignite/ignite-fabric-1.0.0-incubating*

Looked like it needs some freshening up.

Nick, given that you have been managing this docker account, can you please
update it?

D.

Re: docker image

[Sergi Vladykin]

Looks a bit strange for me if most of development and testing happens on
Oracle JDK but
we distribute with OpenJDK. I believe if something works under OpenJDK most
probably
it will under Oracle JDK as well, but not the reverse.

Sergi

2015-09-17 17:13 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:

> On Thu, Sep 17, 2015 at 1:39 PM, Sergi Vladykin <sergi.vlady...@gmail.com>
> wrote:
>
> > Probably it means that we should use openjdk by default for development
> and
> > testing as well?
> >
>
> We can, but I am not sure why we have to. Can you explain?
>
>
> >
> > Sergi
> >
> > 2015-09-17 7:39 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> >
> > > Ignters,
> > >
> > > Can we change our docker image to download the OpenJDK? We should not
> > > automatically download Oracle JDK in the docker image - it is against
> the
> > > license.
> > >
> > > My preference would be to fix it for 1.4 release.
> > >
> > > Thanks,
> > > D.
> > >
> >
>

Re: docker image

[Dmitriy Setrakyan]

On Thu, Sep 17, 2015 at 1:39 PM, Sergi Vladykin <sergi.vlady...@gmail.com>
wrote:

> Probably it means that we should use openjdk by default for development and
> testing as well?
>

We can, but I am not sure why we have to. Can you explain?


>
> Sergi
>
> 2015-09-17 7:39 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
>
> > Ignters,
> >
> > Can we change our docker image to download the OpenJDK? We should not
> > automatically download Oracle JDK in the docker image - it is against the
> > license.
> >
> > My preference would be to fix it for 1.4 release.
> >
> > Thanks,
> > D.
> >
>