Re: Apache Ignite 2.6 - Packages roadmap

[Peter Ivanov]

On Fri, 8 Jun 2018 at 00:37, Denis Magda  wrote:

> Petr,
>
> Am I correct that all 3 points were tested for VirtualBox?


No, it was tested for Windows 10 WSL.


I would
> introduce a documentation sub-section for VirtualBox then.


As I said previously — under “honest” virtual environments (i. e.
VirtualBox, VMWare, Hyper-V, etc.) everything will work just as on the bare
metal. And no special section is required, otherwise you will end up
describing support of every virtualization technology in the world. I would
suggest we wait for some user and dev experience about using packages in
virtual and containerized environments to better understand what should be
mentioned in documentation and what should not.



>
> As for the Windows WSL, did you have a change to look into it?
>
> --
> Denis
>
> On Thu, Jun 7, 2018 at 2:42 AM, Petr Ivanov  wrote:
>
> > Here are the results of checks:
> >
> >
> > 1. Ubuntu. Running Apache Ignite as a stand-alone application works fine,
> > I have successful connections to another Apache Ignite node running under
> > VirtualBox CentOS.
> > NOTE: connectivity started working only after creation of “allow all
> > incoming connections” rule in Windows Defender Firewall.
> >
> > 2. Debian. Running Apache Ignite as a stand-alone application works fine,
> > I have successful connections to another Apache Ignite node running under
> > VirtualBox CentOS.
> > NOTE: in addition to Ubuntu’s NOTE, it is required to install dirmngr
> > program for apt-key be able to download gpg keys over network (this NOTE
> > can be added to documentation + I can add dependency to DEB package in
> next
> > release).
> >
> > 3. SUSE. Has neither APT no YUM commands. RPM package can be installed
> via
> > rpm -i command, but I think that this case is out of Apache Ignite 2.5
> > scope and the question of “officially supported Linux distributions”
> should
> > be discussed separately.
> >
> >
> >
> >
> > > On 7 Jun 2018, at 08:43, Peter Ivanov  wrote:
> > >
> > > Understood. Will do today.
> > >
> > >
> > > On Thu, 7 Jun 2018 at 08:43, Dmitriy Setrakyan  > > wrote:
> > > On Wed, Jun 6, 2018 at 10:40 PM, Peter Ivanov  > > wrote:
> > >
> > > > Dmitriy,
> > > >
> > > >
> > > > What kind of instructions? Systemd or stand-alone?
> > > > I thought we have already agreed that systemd services are not
> > eligible for
> > > > Windows 10 WSL.
> > > >
> > > > So have I to check that Debian, Ubuntu and SUSE environments for
> > Windows 10
> > > > WSL supports running Apache Ignite installed from packages as a
> > stand-alone
> > > > application?
> > > >
> > >
> > > Yes.
> >
> >
>

Re: Apache Ignite 2.6 - Packages roadmap

[Denis Magda]

Petr,

Am I correct that all 3 points were tested for VirtualBox? I would
introduce a documentation sub-section for VirtualBox then.

As for the Windows WSL, did you have a change to look into it?

--
Denis

On Thu, Jun 7, 2018 at 2:42 AM, Petr Ivanov  wrote:

> Here are the results of checks:
>
>
> 1. Ubuntu. Running Apache Ignite as a stand-alone application works fine,
> I have successful connections to another Apache Ignite node running under
> VirtualBox CentOS.
> NOTE: connectivity started working only after creation of “allow all
> incoming connections” rule in Windows Defender Firewall.
>
> 2. Debian. Running Apache Ignite as a stand-alone application works fine,
> I have successful connections to another Apache Ignite node running under
> VirtualBox CentOS.
> NOTE: in addition to Ubuntu’s NOTE, it is required to install dirmngr
> program for apt-key be able to download gpg keys over network (this NOTE
> can be added to documentation + I can add dependency to DEB package in next
> release).
>
> 3. SUSE. Has neither APT no YUM commands. RPM package can be installed via
> rpm -i command, but I think that this case is out of Apache Ignite 2.5
> scope and the question of “officially supported Linux distributions” should
> be discussed separately.
>
>
>
>
> > On 7 Jun 2018, at 08:43, Peter Ivanov  wrote:
> >
> > Understood. Will do today.
> >
> >
> > On Thu, 7 Jun 2018 at 08:43, Dmitriy Setrakyan  > wrote:
> > On Wed, Jun 6, 2018 at 10:40 PM, Peter Ivanov  > wrote:
> >
> > > Dmitriy,
> > >
> > >
> > > What kind of instructions? Systemd or stand-alone?
> > > I thought we have already agreed that systemd services are not
> eligible for
> > > Windows 10 WSL.
> > >
> > > So have I to check that Debian, Ubuntu and SUSE environments for
> Windows 10
> > > WSL supports running Apache Ignite installed from packages as a
> stand-alone
> > > application?
> > >
> >
> > Yes.
>
>

Re: Apache Ignite 2.6 - Packages roadmap

[Petr Ivanov]

Here are the results of checks:


1. Ubuntu. Running Apache Ignite as a stand-alone application works fine, I 
have successful connections to another Apache Ignite node running under 
VirtualBox CentOS.
NOTE: connectivity started working only after creation of “allow all incoming 
connections” rule in Windows Defender Firewall.

2. Debian. Running Apache Ignite as a stand-alone application works fine, I 
have successful connections to another Apache Ignite node running under 
VirtualBox CentOS.
NOTE: in addition to Ubuntu’s NOTE, it is required to install dirmngr program 
for apt-key be able to download gpg keys over network (this NOTE can be added 
to documentation + I can add dependency to DEB package in next release).

3. SUSE. Has neither APT no YUM commands. RPM package can be installed via rpm 
-i command, but I think that this case is out of Apache Ignite 2.5 scope and 
the question of “officially supported Linux distributions” should be discussed 
separately.




> On 7 Jun 2018, at 08:43, Peter Ivanov  wrote:
> 
> Understood. Will do today.
> 
> 
> On Thu, 7 Jun 2018 at 08:43, Dmitriy Setrakyan  > wrote:
> On Wed, Jun 6, 2018 at 10:40 PM, Peter Ivanov  > wrote:
> 
> > Dmitriy,
> >
> >
> > What kind of instructions? Systemd or stand-alone?
> > I thought we have already agreed that systemd services are not eligible for
> > Windows 10 WSL.
> >
> > So have I to check that Debian, Ubuntu and SUSE environments for Windows 10
> > WSL supports running Apache Ignite installed from packages as a stand-alone
> > application?
> >
> 
> Yes.

Re: Apache Ignite 2.6 - Packages roadmap

[Peter Ivanov]

Understood. Will do today.


On Thu, 7 Jun 2018 at 08:43, Dmitriy Setrakyan 
wrote:

> On Wed, Jun 6, 2018 at 10:40 PM, Peter Ivanov  wrote:
>
> > Dmitriy,
> >
> >
> > What kind of instructions? Systemd or stand-alone?
> > I thought we have already agreed that systemd services are not eligible
> for
> > Windows 10 WSL.
> >
> > So have I to check that Debian, Ubuntu and SUSE environments for Windows
> 10
> > WSL supports running Apache Ignite installed from packages as a
> stand-alone
> > application?
> >
>
> Yes.
>

Re: Apache Ignite 2.6 - Packages roadmap

[Dmitriy Setrakyan]

On Wed, Jun 6, 2018 at 10:40 PM, Peter Ivanov  wrote:

> Dmitriy,
>
>
> What kind of instructions? Systemd or stand-alone?
> I thought we have already agreed that systemd services are not eligible for
> Windows 10 WSL.
>
> So have I to check that Debian, Ubuntu and SUSE environments for Windows 10
> WSL supports running Apache Ignite installed from packages as a stand-alone
> application?
>

Yes.

Re: Apache Ignite 2.6 - Packages roadmap

[Peter Ivanov]

Dmitriy,


What kind of instructions? Systemd or stand-alone?
I thought we have already agreed that systemd services are not eligible for
Windows 10 WSL.

So have I to check that Debian, Ubuntu and SUSE environments for Windows 10
WSL supports running Apache Ignite installed from packages as a stand-alone
application?



On Thu, 7 Jun 2018 at 08:01, Dmitriy Setrakyan 
wrote:

> Petr,
>
> I confirm that Ignite starts for me from a downloadable archive on Ubuntu
> under Windows 10.
>
> I would actually recommend that instead of discussing here how running
> Linux in Windows 10 is not a valid use case, we should probably just test
> it and fix it. Can you please try running your instructions in Ubuntu,
> Debian, and Suse on Windows 10 and confirm that they work for you?
>
> None of them have worked for me so far. I consider this to be a critical
> issue.
>
> D.
>
> On Wed, Jun 6, 2018 at 9:44 PM, Peter Ivanov  wrote:
>
> > Denis,
> >
> >
> > The question “will Apache Ignite start under Windows 10 WSL Ubuntu from
> > packages?” is the same as “will Apache Ignite start under Windows 10 WSL
> > Ubuntu from binary archive?” concerning running Apache Ignite as
> standalone
> > service (from ignite.sh). Did anyone from community tried running Apache
> > Ignite from the binary archive under Windows 10 WSL Ubuntu?
> >
> > So the problem is not the package itself, but environment. When I was
> > preparing packages - there was no mention about complex experimental
> > environments which should be supported, so I do not understand
> > this aggresive criticism concerning revealed problem.
> >
> > Of course, I will check running Apache Ignite from packages under Windows
> > 10 WSL Ubuntu as a stand-alone application, but, IMO, that had to be done
> > as soon as Windows 10 WSL Ubuntu environment was introduced in the first
> > place, yet, I do not see such thread among dev-list discussions.
> >
> >
> >
> > On Thu, 7 Jun 2018 at 03:02, Denis Magda  wrote:
> >
> > > Stop. I've finally figured out what kind of environment Dmitriy is
> > talking
> > > about.
> > >
> > > Imagine a Windows developer who needs to run something under Linux on
> his
> > > machine. He/she would go for VirtualBox and Parallels Desktop. Hope, we
> > > don't have any doubts that it needs to be possible to install Ignite
> via
> > > DEB|RPM in those virtual environments.
> > >
> > > Dmitriy, is talking about an alternate solution for VirtualBox and
> > > Parallels that became default since Windows 10.
> > >
> > > Considering this we must ensure Ignite RPM|DEB works there. Backing up
> > > Dmitriy.
> > >
> > > Petr, do you have access to a Windows 10 machine?
> > >
> > > --
> > > Denis
> > >
> > >
> > > On Wed, Jun 6, 2018 at 9:56 AM, Peter Ivanov 
> > wrote:
> > >
> > > > Denis,
> > > >
> > > >
> > > > I’ll look into it
> > > >
> > > >
> > > > On Wed, 6 Jun 2018 at 19:17, Denis Magda  wrote:
> > > >
> > > > > I suggest us trying to move the conversation in this direction.
> > > > >
> > > > > Is it possible to install and run Cassandra using DEB from that
> > > emulation
> > > > > environment on Windows? If yes, then we should spend our efforts
> > > adopting
> > > > > Ignite for the environment. Otherwise, we should skip it for now.
> > > > >
> > > > > --
> > > > > Denis
> > > > >
> > > > > On Tue, Jun 5, 2018 at 5:57 PM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov <
> mr.wei...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Dmitriy,
> > > > > > >
> > > > > > >
> > > > > > > I will check soon and see what can be done to overcome this.
> > > > > > >
> > > > > >
> > > > > > Thanks! Looking forward to your feedback.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Yet, I still doubt that running Apache Ignite packed in DEB
> under
> > > > > Windows
> > > > > > > 10 WSL Ubuntu is a plausible user case.
> > > > > > >
> > > > > >
> > > > > > Disagree, it will be used during development, not production.
> > Windows
> > > > 10
> > > > > > supports a clean way of running Linux - you simply just download
> > and
> > > > > > install it from the Windows app store. Many developers who use
> > > Windows
> > > > > will
> > > > > > try it.
> > > > > >
> > > > > >
> > > > > > > To be honest, I doubt that our packages are being downloaded
> and
> > > > > > installed
> > > > > > > at all...
> > > > > > >
> > > > > >
> > > > > > Well, if we keep the packages unusable, then no one will ever use
> > > them.
> > > > > > Many people likely tried and gave up. Let's make sure that after
> > you
> > > > > > address all the issues, the experience with packages will be
> > smooth.
> > > > > >
> > > > > > D.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Apache Ignite 2.6 - Packages roadmap

[Dmitriy Setrakyan]

Petr,

I confirm that Ignite starts for me from a downloadable archive on Ubuntu
under Windows 10.

I would actually recommend that instead of discussing here how running
Linux in Windows 10 is not a valid use case, we should probably just test
it and fix it. Can you please try running your instructions in Ubuntu,
Debian, and Suse on Windows 10 and confirm that they work for you?

None of them have worked for me so far. I consider this to be a critical
issue.

D.

On Wed, Jun 6, 2018 at 9:44 PM, Peter Ivanov  wrote:

> Denis,
>
>
> The question “will Apache Ignite start under Windows 10 WSL Ubuntu from
> packages?” is the same as “will Apache Ignite start under Windows 10 WSL
> Ubuntu from binary archive?” concerning running Apache Ignite as standalone
> service (from ignite.sh). Did anyone from community tried running Apache
> Ignite from the binary archive under Windows 10 WSL Ubuntu?
>
> So the problem is not the package itself, but environment. When I was
> preparing packages - there was no mention about complex experimental
> environments which should be supported, so I do not understand
> this aggresive criticism concerning revealed problem.
>
> Of course, I will check running Apache Ignite from packages under Windows
> 10 WSL Ubuntu as a stand-alone application, but, IMO, that had to be done
> as soon as Windows 10 WSL Ubuntu environment was introduced in the first
> place, yet, I do not see such thread among dev-list discussions.
>
>
>
> On Thu, 7 Jun 2018 at 03:02, Denis Magda  wrote:
>
> > Stop. I've finally figured out what kind of environment Dmitriy is
> talking
> > about.
> >
> > Imagine a Windows developer who needs to run something under Linux on his
> > machine. He/she would go for VirtualBox and Parallels Desktop. Hope, we
> > don't have any doubts that it needs to be possible to install Ignite via
> > DEB|RPM in those virtual environments.
> >
> > Dmitriy, is talking about an alternate solution for VirtualBox and
> > Parallels that became default since Windows 10.
> >
> > Considering this we must ensure Ignite RPM|DEB works there. Backing up
> > Dmitriy.
> >
> > Petr, do you have access to a Windows 10 machine?
> >
> > --
> > Denis
> >
> >
> > On Wed, Jun 6, 2018 at 9:56 AM, Peter Ivanov 
> wrote:
> >
> > > Denis,
> > >
> > >
> > > I’ll look into it
> > >
> > >
> > > On Wed, 6 Jun 2018 at 19:17, Denis Magda  wrote:
> > >
> > > > I suggest us trying to move the conversation in this direction.
> > > >
> > > > Is it possible to install and run Cassandra using DEB from that
> > emulation
> > > > environment on Windows? If yes, then we should spend our efforts
> > adopting
> > > > Ignite for the environment. Otherwise, we should skip it for now.
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Tue, Jun 5, 2018 at 5:57 PM, Dmitriy Setrakyan <
> > dsetrak...@apache.org
> > > >
> > > > wrote:
> > > >
> > > > > On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov 
> > > > wrote:
> > > > >
> > > > > > Dmitriy,
> > > > > >
> > > > > >
> > > > > > I will check soon and see what can be done to overcome this.
> > > > > >
> > > > >
> > > > > Thanks! Looking forward to your feedback.
> > > > >
> > > > >
> > > > > >
> > > > > > Yet, I still doubt that running Apache Ignite packed in DEB under
> > > > Windows
> > > > > > 10 WSL Ubuntu is a plausible user case.
> > > > > >
> > > > >
> > > > > Disagree, it will be used during development, not production.
> Windows
> > > 10
> > > > > supports a clean way of running Linux - you simply just download
> and
> > > > > install it from the Windows app store. Many developers who use
> > Windows
> > > > will
> > > > > try it.
> > > > >
> > > > >
> > > > > > To be honest, I doubt that our packages are being downloaded and
> > > > > installed
> > > > > > at all...
> > > > > >
> > > > >
> > > > > Well, if we keep the packages unusable, then no one will ever use
> > them.
> > > > > Many people likely tried and gave up. Let's make sure that after
> you
> > > > > address all the issues, the experience with packages will be
> smooth.
> > > > >
> > > > > D.
> > > > >
> > > >
> > >
> >
>

Re: Apache Ignite 2.6 - Packages roadmap

[Peter Ivanov]

Denis,


The question “will Apache Ignite start under Windows 10 WSL Ubuntu from
packages?” is the same as “will Apache Ignite start under Windows 10 WSL
Ubuntu from binary archive?” concerning running Apache Ignite as standalone
service (from ignite.sh). Did anyone from community tried running Apache
Ignite from the binary archive under Windows 10 WSL Ubuntu?

So the problem is not the package itself, but environment. When I was
preparing packages - there was no mention about complex experimental
environments which should be supported, so I do not understand
this aggresive criticism concerning revealed problem.

Of course, I will check running Apache Ignite from packages under Windows
10 WSL Ubuntu as a stand-alone application, but, IMO, that had to be done
as soon as Windows 10 WSL Ubuntu environment was introduced in the first
place, yet, I do not see such thread among dev-list discussions.



On Thu, 7 Jun 2018 at 03:02, Denis Magda  wrote:

> Stop. I've finally figured out what kind of environment Dmitriy is talking
> about.
>
> Imagine a Windows developer who needs to run something under Linux on his
> machine. He/she would go for VirtualBox and Parallels Desktop. Hope, we
> don't have any doubts that it needs to be possible to install Ignite via
> DEB|RPM in those virtual environments.
>
> Dmitriy, is talking about an alternate solution for VirtualBox and
> Parallels that became default since Windows 10.
>
> Considering this we must ensure Ignite RPM|DEB works there. Backing up
> Dmitriy.
>
> Petr, do you have access to a Windows 10 machine?
>
> --
> Denis
>
>
> On Wed, Jun 6, 2018 at 9:56 AM, Peter Ivanov  wrote:
>
> > Denis,
> >
> >
> > I’ll look into it
> >
> >
> > On Wed, 6 Jun 2018 at 19:17, Denis Magda  wrote:
> >
> > > I suggest us trying to move the conversation in this direction.
> > >
> > > Is it possible to install and run Cassandra using DEB from that
> emulation
> > > environment on Windows? If yes, then we should spend our efforts
> adopting
> > > Ignite for the environment. Otherwise, we should skip it for now.
> > >
> > > --
> > > Denis
> > >
> > > On Tue, Jun 5, 2018 at 5:57 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >
> > > wrote:
> > >
> > > > On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov 
> > > wrote:
> > > >
> > > > > Dmitriy,
> > > > >
> > > > >
> > > > > I will check soon and see what can be done to overcome this.
> > > > >
> > > >
> > > > Thanks! Looking forward to your feedback.
> > > >
> > > >
> > > > >
> > > > > Yet, I still doubt that running Apache Ignite packed in DEB under
> > > Windows
> > > > > 10 WSL Ubuntu is a plausible user case.
> > > > >
> > > >
> > > > Disagree, it will be used during development, not production. Windows
> > 10
> > > > supports a clean way of running Linux - you simply just download and
> > > > install it from the Windows app store. Many developers who use
> Windows
> > > will
> > > > try it.
> > > >
> > > >
> > > > > To be honest, I doubt that our packages are being downloaded and
> > > > installed
> > > > > at all...
> > > > >
> > > >
> > > > Well, if we keep the packages unusable, then no one will ever use
> them.
> > > > Many people likely tried and gave up. Let's make sure that after you
> > > > address all the issues, the experience with packages will be smooth.
> > > >
> > > > D.
> > > >
> > >
> >
>

Re: Apache Ignite 2.6 - Packages roadmap

[Denis Magda]

Stop. I've finally figured out what kind of environment Dmitriy is talking
about.

Imagine a Windows developer who needs to run something under Linux on his
machine. He/she would go for VirtualBox and Parallels Desktop. Hope, we
don't have any doubts that it needs to be possible to install Ignite via
DEB|RPM in those virtual environments.

Dmitriy, is talking about an alternate solution for VirtualBox and
Parallels that became default since Windows 10.

Considering this we must ensure Ignite RPM|DEB works there. Backing up
Dmitriy.

Petr, do you have access to a Windows 10 machine?

--
Denis


On Wed, Jun 6, 2018 at 9:56 AM, Peter Ivanov  wrote:

> Denis,
>
>
> I’ll look into it
>
>
> On Wed, 6 Jun 2018 at 19:17, Denis Magda  wrote:
>
> > I suggest us trying to move the conversation in this direction.
> >
> > Is it possible to install and run Cassandra using DEB from that emulation
> > environment on Windows? If yes, then we should spend our efforts adopting
> > Ignite for the environment. Otherwise, we should skip it for now.
> >
> > --
> > Denis
> >
> > On Tue, Jun 5, 2018 at 5:57 PM, Dmitriy Setrakyan  >
> > wrote:
> >
> > > On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov 
> > wrote:
> > >
> > > > Dmitriy,
> > > >
> > > >
> > > > I will check soon and see what can be done to overcome this.
> > > >
> > >
> > > Thanks! Looking forward to your feedback.
> > >
> > >
> > > >
> > > > Yet, I still doubt that running Apache Ignite packed in DEB under
> > Windows
> > > > 10 WSL Ubuntu is a plausible user case.
> > > >
> > >
> > > Disagree, it will be used during development, not production. Windows
> 10
> > > supports a clean way of running Linux - you simply just download and
> > > install it from the Windows app store. Many developers who use Windows
> > will
> > > try it.
> > >
> > >
> > > > To be honest, I doubt that our packages are being downloaded and
> > > installed
> > > > at all...
> > > >
> > >
> > > Well, if we keep the packages unusable, then no one will ever use them.
> > > Many people likely tried and gave up. Let's make sure that after you
> > > address all the issues, the experience with packages will be smooth.
> > >
> > > D.
> > >
> >
>

Re: Apache Ignite 2.6 - Packages roadmap

[Peter Ivanov]

Denis,


I’ll look into it


On Wed, 6 Jun 2018 at 19:17, Denis Magda  wrote:

> I suggest us trying to move the conversation in this direction.
>
> Is it possible to install and run Cassandra using DEB from that emulation
> environment on Windows? If yes, then we should spend our efforts adopting
> Ignite for the environment. Otherwise, we should skip it for now.
>
> --
> Denis
>
> On Tue, Jun 5, 2018 at 5:57 PM, Dmitriy Setrakyan 
> wrote:
>
> > On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov 
> wrote:
> >
> > > Dmitriy,
> > >
> > >
> > > I will check soon and see what can be done to overcome this.
> > >
> >
> > Thanks! Looking forward to your feedback.
> >
> >
> > >
> > > Yet, I still doubt that running Apache Ignite packed in DEB under
> Windows
> > > 10 WSL Ubuntu is a plausible user case.
> > >
> >
> > Disagree, it will be used during development, not production. Windows 10
> > supports a clean way of running Linux - you simply just download and
> > install it from the Windows app store. Many developers who use Windows
> will
> > try it.
> >
> >
> > > To be honest, I doubt that our packages are being downloaded and
> > installed
> > > at all...
> > >
> >
> > Well, if we keep the packages unusable, then no one will ever use them.
> > Many people likely tried and gave up. Let's make sure that after you
> > address all the issues, the experience with packages will be smooth.
> >
> > D.
> >
>

Re: Apache Ignite 2.6 - Packages roadmap

[Denis Magda]

I suggest us trying to move the conversation in this direction.

Is it possible to install and run Cassandra using DEB from that emulation
environment on Windows? If yes, then we should spend our efforts adopting
Ignite for the environment. Otherwise, we should skip it for now.

--
Denis

On Tue, Jun 5, 2018 at 5:57 PM, Dmitriy Setrakyan 
wrote:

> On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov  wrote:
>
> > Dmitriy,
> >
> >
> > I will check soon and see what can be done to overcome this.
> >
>
> Thanks! Looking forward to your feedback.
>
>
> >
> > Yet, I still doubt that running Apache Ignite packed in DEB under Windows
> > 10 WSL Ubuntu is a plausible user case.
> >
>
> Disagree, it will be used during development, not production. Windows 10
> supports a clean way of running Linux - you simply just download and
> install it from the Windows app store. Many developers who use Windows will
> try it.
>
>
> > To be honest, I doubt that our packages are being downloaded and
> installed
> > at all...
> >
>
> Well, if we keep the packages unusable, then no one will ever use them.
> Many people likely tried and gave up. Let's make sure that after you
> address all the issues, the experience with packages will be smooth.
>
> D.
>

Re: Apache Ignite 2.6 - Packages roadmap

[Dmitriy Setrakyan]

On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov  wrote:

> Dmitriy,
>
>
> I will check soon and see what can be done to overcome this.
>

Thanks! Looking forward to your feedback.


>
> Yet, I still doubt that running Apache Ignite packed in DEB under Windows
> 10 WSL Ubuntu is a plausible user case.
>

Disagree, it will be used during development, not production. Windows 10
supports a clean way of running Linux - you simply just download and
install it from the Windows app store. Many developers who use Windows will
try it.


> To be honest, I doubt that our packages are being downloaded and installed
> at all...
>

Well, if we keep the packages unusable, then no one will ever use them.
Many people likely tried and gave up. Let's make sure that after you
address all the issues, the experience with packages will be smooth.

D.

Re: Apache Ignite 2.6 - Packages roadmap

[Dmitriy Setrakyan]

On Tue, Jun 5, 2018 at 1:54 PM, Sergey Kozlov  wrote:

> Hi
>
> For Windows users we should provide Windows installer (.exe or .msi) that
> set up and install AI as service. But that task requires significant
> efforts  and makes sense to start in that way after stabilization DEB/RPM
> architecture
>

I am not sure we need a windows installer. I am trying to get this to work
for those developers who run Linux inside Windows, which is cleanly
supported in Windows 10.

Re: Apache Ignite 2.6 - Packages roadmap

[Sergey Kozlov]

Hi

For Windows users we should provide Windows installer (.exe or .msi) that
set up and install AI as service. But that task requires significant
efforts  and makes sense to start in that way after stabilization DEB/RPM
architecture

On Tue, Jun 5, 2018 at 10:12 PM, Petr Ivanov  wrote:

> Dmitriy,
>
>
> I will check soon and see what can be done to overcome this.
>
> Yet, I still doubt that running Apache Ignite packed in DEB under Windows
> 10 WSL Ubuntu is a plausible user case.
> To be honest, I doubt that our packages are being downloaded and installed
> at all...
>
>
>
>
> > On 5 Jun 2018, at 21:26, Dmitriy Setrakyan 
> wrote:
> >
> > Petr,
> >
> > Were you ever able to successfully start an Ignite node from Ubuntu on
> > Windows 10?
> >
> > It looks like a node startup hangs for me. Here is the message I am
> getting
> > when bringing up a node in verbose mode:
> >
> > *[18:24:27,778][WARNING][main][TcpDiscoverySpi] Node has not been
> connected
> >> to topology and will repeat join process. Check remote nodes logs for
> >> possible error messages. Note that large topology may require
> significant
> >> time to start. Increase 'TcpDiscoverySpi.networkTimeout' configuration
> >> property if getting this message on the starting nodes
> >> [networkTimeout=5000]*
> >
> >
> > Just by looking how much I am struggling to bring up a node, I can only
> > imagine what our poor users are going through when trying this out.
> >
> > D.
> >
> > On Tue, Jun 5, 2018 at 2:06 AM, Petr Ivanov  wrote:
> >
> >> Dmitriy,
> >>
> >>
> >> I’ve replaced root user requirement with ignite user requirement. It is
> >> necessary because after installation ignite user receive all Apache
> Ignite
> >> work directories ownership (to be able to write woking files there).
> >> In fact, Apache Ignite as a service is configured to run just under the
> >> same user — ignite.
> >>
> >> So — it is yes and no. Issuing systemctl command and editing
> configuration
> >> files at /etc/apache-ignite does require root permissions, however the
> >> Apache Ignite Java process itself runs under unprivileged user ignite
> with
> >> no password and no login shell, thus making running process
> significantly
> >> less susceptible to outside impact.
> >> And to be able to run Apache Ignite as a standalone process — it is
> enough
> >> to login as ignite user (as it is mentioned in documentation) and run
> >> ignite.sh as usual.
> >>
> >>
> >>
> >>
> >>> On 5 Jun 2018, at 08:00, Dmitriy Setrakyan 
> >> wrote:
> >>>
> >>> Petr,
> >>>
> >>> I think it was Denis who reworked the documentation. In any case, if
> you
> >>> see something lacking you can fix it.
> >>>
> >>> Just to clarify, are you suggesting that you don't have to be root to
> run
> >>> the Ignite process after the package install?
> >>>
> >>> D.
> >>>
> >>> On Mon, Jun 4, 2018 at 9:31 PM, Petr Ivanov 
> wrote:
> >>>
> > 1. Remove the requirement to run Ignite scripts as root. This will be
> >> a
> > huge No in most environment and we should fix it.
> 
> 
> > There is already a ticket for point 1:
> > https://issues.apache.org/jira/browse/IGNITE-8695 <
>  https://issues.apache.org/jira/browse/IGNITE-8695>
> 
>  1. I am not the author of this part of instruction — someone, who
>  completely reworked that section about running ignite as standalone
> >> process
>  should also remove / rework the “require root permissions” part
> because
> >> in
>  my version of documentation there was requirement to run as root, but
>  requirement to run as ignite user (logining in into it with specified
>  shell, because it is disabled by default — as it should be done for
> >> every
>  service) due to packages’ postinstall scripts that assign ignite user
>  permissions on all Apache Ignite directories.
> 
> 
> > 2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be
> > executable without specifying the whole path name (not sure if it is
> > already done or not)
> 
>  2. We should not. Instead, we have to symlink all required scripts
> from
>  bin/ to /usr/bin, providing changes to scripts it selves, so that they
> >> can
>  be called from /usr/bin as if from $IGNITE_HOME ('readlink' command to
> >> find
>  real symlink location).
> 
> 
> > I do remember the multi-package approach was suggested as a solution
> to
> > trim down the size of the binary that is hosted by ASF. Since now the
> > binaries are hosted in Bintray, do we still have that issue? If it's
> >> fine
> > to preload and keep big binaries in Bintray then I would suggest us
> to
> > postpone the multi-package activities until there is a real demand.
> 
> 
>  3. The multi-package approach was also suggested for more accurate
>  architecture and more flexible updates. And working with smaller
> >> packages
>  on development stage is too more reliable and easy.
>  Yes, we can 

Re: Apache Ignite 2.6 - Packages roadmap

[Petr Ivanov]

Dmitriy,


I will check soon and see what can be done to overcome this.

Yet, I still doubt that running Apache Ignite packed in DEB under Windows 10 
WSL Ubuntu is a plausible user case.
To be honest, I doubt that our packages are being downloaded and installed at 
all...




> On 5 Jun 2018, at 21:26, Dmitriy Setrakyan  wrote:
> 
> Petr,
> 
> Were you ever able to successfully start an Ignite node from Ubuntu on
> Windows 10?
> 
> It looks like a node startup hangs for me. Here is the message I am getting
> when bringing up a node in verbose mode:
> 
> *[18:24:27,778][WARNING][main][TcpDiscoverySpi] Node has not been connected
>> to topology and will repeat join process. Check remote nodes logs for
>> possible error messages. Note that large topology may require significant
>> time to start. Increase 'TcpDiscoverySpi.networkTimeout' configuration
>> property if getting this message on the starting nodes
>> [networkTimeout=5000]*
> 
> 
> Just by looking how much I am struggling to bring up a node, I can only
> imagine what our poor users are going through when trying this out.
> 
> D.
> 
> On Tue, Jun 5, 2018 at 2:06 AM, Petr Ivanov  wrote:
> 
>> Dmitriy,
>> 
>> 
>> I’ve replaced root user requirement with ignite user requirement. It is
>> necessary because after installation ignite user receive all Apache Ignite
>> work directories ownership (to be able to write woking files there).
>> In fact, Apache Ignite as a service is configured to run just under the
>> same user — ignite.
>> 
>> So — it is yes and no. Issuing systemctl command and editing configuration
>> files at /etc/apache-ignite does require root permissions, however the
>> Apache Ignite Java process itself runs under unprivileged user ignite with
>> no password and no login shell, thus making running process significantly
>> less susceptible to outside impact.
>> And to be able to run Apache Ignite as a standalone process — it is enough
>> to login as ignite user (as it is mentioned in documentation) and run
>> ignite.sh as usual.
>> 
>> 
>> 
>> 
>>> On 5 Jun 2018, at 08:00, Dmitriy Setrakyan 
>> wrote:
>>> 
>>> Petr,
>>> 
>>> I think it was Denis who reworked the documentation. In any case, if you
>>> see something lacking you can fix it.
>>> 
>>> Just to clarify, are you suggesting that you don't have to be root to run
>>> the Ignite process after the package install?
>>> 
>>> D.
>>> 
>>> On Mon, Jun 4, 2018 at 9:31 PM, Petr Ivanov  wrote:
>>> 
> 1. Remove the requirement to run Ignite scripts as root. This will be
>> a
> huge No in most environment and we should fix it.
 
 
> There is already a ticket for point 1:
> https://issues.apache.org/jira/browse/IGNITE-8695 <
 https://issues.apache.org/jira/browse/IGNITE-8695>
 
 1. I am not the author of this part of instruction — someone, who
 completely reworked that section about running ignite as standalone
>> process
 should also remove / rework the “require root permissions” part because
>> in
 my version of documentation there was requirement to run as root, but
 requirement to run as ignite user (logining in into it with specified
 shell, because it is disabled by default — as it should be done for
>> every
 service) due to packages’ postinstall scripts that assign ignite user
 permissions on all Apache Ignite directories.
 
 
> 2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be
> executable without specifying the whole path name (not sure if it is
> already done or not)
 
 2. We should not. Instead, we have to symlink all required scripts from
 bin/ to /usr/bin, providing changes to scripts it selves, so that they
>> can
 be called from /usr/bin as if from $IGNITE_HOME ('readlink' command to
>> find
 real symlink location).
 
 
> I do remember the multi-package approach was suggested as a solution to
> trim down the size of the binary that is hosted by ASF. Since now the
> binaries are hosted in Bintray, do we still have that issue? If it's
>> fine
> to preload and keep big binaries in Bintray then I would suggest us to
> postpone the multi-package activities until there is a real demand.
 
 
 3. The multi-package approach was also suggested for more accurate
 architecture and more flexible updates. And working with smaller
>> packages
 on development stage is too more reliable and easy.
 Yes, we can postpone it (for how long?) but I’d like to insist on
>> proposed
 layout (and reimplement it rather quickly), because ta least it shows
>> our
 packages as more mature (no one ships theirs software in single monolith
 package, especially in official repositories).
 
 
> - Make sqlline.sh callable from command line (PATH). E.g. symlink it as
> /usr/bin/sqlline-ignite, make sure it works.
> - Fix control.sh and visor-cmd, expose them too.
 
 4. See p.2. Indeed they need to be fixes and 

Re: Apache Ignite 2.6 - Packages roadmap

[Dmitriy Setrakyan]

Petr,

Were you ever able to successfully start an Ignite node from Ubuntu on
Windows 10?

It looks like a node startup hangs for me. Here is the message I am getting
when bringing up a node in verbose mode:

*[18:24:27,778][WARNING][main][TcpDiscoverySpi] Node has not been connected
> to topology and will repeat join process. Check remote nodes logs for
> possible error messages. Note that large topology may require significant
> time to start. Increase 'TcpDiscoverySpi.networkTimeout' configuration
> property if getting this message on the starting nodes
> [networkTimeout=5000]*


Just by looking how much I am struggling to bring up a node, I can only
imagine what our poor users are going through when trying this out.

D.

On Tue, Jun 5, 2018 at 2:06 AM, Petr Ivanov  wrote:

> Dmitriy,
>
>
> I’ve replaced root user requirement with ignite user requirement. It is
> necessary because after installation ignite user receive all Apache Ignite
> work directories ownership (to be able to write woking files there).
> In fact, Apache Ignite as a service is configured to run just under the
> same user — ignite.
>
> So — it is yes and no. Issuing systemctl command and editing configuration
> files at /etc/apache-ignite does require root permissions, however the
> Apache Ignite Java process itself runs under unprivileged user ignite with
> no password and no login shell, thus making running process significantly
> less susceptible to outside impact.
> And to be able to run Apache Ignite as a standalone process — it is enough
> to login as ignite user (as it is mentioned in documentation) and run
> ignite.sh as usual.
>
>
>
>
> > On 5 Jun 2018, at 08:00, Dmitriy Setrakyan 
> wrote:
> >
> > Petr,
> >
> > I think it was Denis who reworked the documentation. In any case, if you
> > see something lacking you can fix it.
> >
> > Just to clarify, are you suggesting that you don't have to be root to run
> > the Ignite process after the package install?
> >
> > D.
> >
> > On Mon, Jun 4, 2018 at 9:31 PM, Petr Ivanov  wrote:
> >
> >>>  1. Remove the requirement to run Ignite scripts as root. This will be
> a
> >>>  huge No in most environment and we should fix it.
> >>
> >>
> >>> There is already a ticket for point 1:
> >>> https://issues.apache.org/jira/browse/IGNITE-8695 <
> >> https://issues.apache.org/jira/browse/IGNITE-8695>
> >>
> >> 1. I am not the author of this part of instruction — someone, who
> >> completely reworked that section about running ignite as standalone
> process
> >> should also remove / rework the “require root permissions” part because
> in
> >> my version of documentation there was requirement to run as root, but
> >> requirement to run as ignite user (logining in into it with specified
> >> shell, because it is disabled by default — as it should be done for
> every
> >> service) due to packages’ postinstall scripts that assign ignite user
> >> permissions on all Apache Ignite directories.
> >>
> >>
> >>>  2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be
> >>>  executable without specifying the whole path name (not sure if it is
> >>>  already done or not)
> >>
> >> 2. We should not. Instead, we have to symlink all required scripts from
> >> bin/ to /usr/bin, providing changes to scripts it selves, so that they
> can
> >> be called from /usr/bin as if from $IGNITE_HOME ('readlink' command to
> find
> >> real symlink location).
> >>
> >>
> >>> I do remember the multi-package approach was suggested as a solution to
> >>> trim down the size of the binary that is hosted by ASF. Since now the
> >>> binaries are hosted in Bintray, do we still have that issue? If it's
> fine
> >>> to preload and keep big binaries in Bintray then I would suggest us to
> >>> postpone the multi-package activities until there is a real demand.
> >>
> >>
> >> 3. The multi-package approach was also suggested for more accurate
> >> architecture and more flexible updates. And working with smaller
> packages
> >> on development stage is too more reliable and easy.
> >> Yes, we can postpone it (for how long?) but I’d like to insist on
> proposed
> >> layout (and reimplement it rather quickly), because ta least it shows
> our
> >> packages as more mature (no one ships theirs software in single monolith
> >> package, especially in official repositories).
> >>
> >>
> >>> - Make sqlline.sh callable from command line (PATH). E.g. symlink it as
> >>> /usr/bin/sqlline-ignite, make sure it works.
> >>> - Fix control.sh and visor-cmd, expose them too.
> >>
> >> 4. See p.2. Indeed they need to be fixes and exposes 'by the book’.
> >>
> >>
> >>> - Allow specifying of JDK implementation and JDK arguments for Apache
> >>> Ignite startup. Preferably on per configuration basis.
> >>
> >> 5. Agree. We need some kind of 'setenv.sh’ for user-side JDK
> configuration.
> >>
> >>
> >>> - Allow adding-removing "modules" to classpath of Ignite - again,
> >>> preferably on per configuration basis. E.g. what happens if I want to
> >> turn
> 

Re: Apache Ignite 2.6 - Packages roadmap

[Petr Ivanov]

Dmitriy,


I’ve replaced root user requirement with ignite user requirement. It is 
necessary because after installation ignite user receive all Apache Ignite work 
directories ownership (to be able to write woking files there).
In fact, Apache Ignite as a service is configured to run just under the same 
user — ignite.

So — it is yes and no. Issuing systemctl command and editing configuration 
files at /etc/apache-ignite does require root permissions, however the Apache 
Ignite Java process itself runs under unprivileged user ignite with no password 
and no login shell, thus making running process significantly less susceptible 
to outside impact.
And to be able to run Apache Ignite as a standalone process — it is enough to 
login as ignite user (as it is mentioned in documentation) and run ignite.sh as 
usual.




> On 5 Jun 2018, at 08:00, Dmitriy Setrakyan  wrote:
> 
> Petr,
> 
> I think it was Denis who reworked the documentation. In any case, if you
> see something lacking you can fix it.
> 
> Just to clarify, are you suggesting that you don't have to be root to run
> the Ignite process after the package install?
> 
> D.
> 
> On Mon, Jun 4, 2018 at 9:31 PM, Petr Ivanov  wrote:
> 
>>>  1. Remove the requirement to run Ignite scripts as root. This will be a
>>>  huge No in most environment and we should fix it.
>> 
>> 
>>> There is already a ticket for point 1:
>>> https://issues.apache.org/jira/browse/IGNITE-8695 <
>> https://issues.apache.org/jira/browse/IGNITE-8695>
>> 
>> 1. I am not the author of this part of instruction — someone, who
>> completely reworked that section about running ignite as standalone process
>> should also remove / rework the “require root permissions” part because in
>> my version of documentation there was requirement to run as root, but
>> requirement to run as ignite user (logining in into it with specified
>> shell, because it is disabled by default — as it should be done for every
>> service) due to packages’ postinstall scripts that assign ignite user
>> permissions on all Apache Ignite directories.
>> 
>> 
>>>  2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be
>>>  executable without specifying the whole path name (not sure if it is
>>>  already done or not)
>> 
>> 2. We should not. Instead, we have to symlink all required scripts from
>> bin/ to /usr/bin, providing changes to scripts it selves, so that they can
>> be called from /usr/bin as if from $IGNITE_HOME ('readlink' command to find
>> real symlink location).
>> 
>> 
>>> I do remember the multi-package approach was suggested as a solution to
>>> trim down the size of the binary that is hosted by ASF. Since now the
>>> binaries are hosted in Bintray, do we still have that issue? If it's fine
>>> to preload and keep big binaries in Bintray then I would suggest us to
>>> postpone the multi-package activities until there is a real demand.
>> 
>> 
>> 3. The multi-package approach was also suggested for more accurate
>> architecture and more flexible updates. And working with smaller packages
>> on development stage is too more reliable and easy.
>> Yes, we can postpone it (for how long?) but I’d like to insist on proposed
>> layout (and reimplement it rather quickly), because ta least it shows our
>> packages as more mature (no one ships theirs software in single monolith
>> package, especially in official repositories).
>> 
>> 
>>> - Make sqlline.sh callable from command line (PATH). E.g. symlink it as
>>> /usr/bin/sqlline-ignite, make sure it works.
>>> - Fix control.sh and visor-cmd, expose them too.
>> 
>> 4. See p.2. Indeed they need to be fixes and exposes 'by the book’.
>> 
>> 
>>> - Allow specifying of JDK implementation and JDK arguments for Apache
>>> Ignite startup. Preferably on per configuration basis.
>> 
>> 5. Agree. We need some kind of 'setenv.sh’ for user-side JDK configuration.
>> 
>> 
>>> - Allow adding-removing "modules" to classpath of Ignite - again,
>>> preferably on per configuration basis. E.g. what happens if I want to
>> turn
>>> ON geospatial/
>> 
>> 6. Agree, was thinking of it too, in form of 'a2enmod'-like utility for
>> enabling / disabling optional libs and modules.
>> 
>> 
>>> - [OPTIONAL] Ship Apache Ignite with a special config which only listens
>> on
>>> localhost. This is for lazy people who can get into trouble by installing
>>> package without looking without security implications.
>> 
>> 7. Arguable. Even if we create such config and put into delivery, there is
>> no guarantee that user will read documentation about necessity of using
>> this special config for security reasons.
>> I would add BIG warning text to Ignite’s log about security implications
>> of unprotected cluster.
>> 
>> 
>>> With regards to splitting package, I think we could have a few of them
>>> (a-i-core, a-i-doc, a-i-c++, a-i-.net) but I don't think we need to have
>> a
>>> half dozen of those right away. This was mostly realised as an
>> antipattern.
>> 
>> 8. I would at least 

Re: Apache Ignite 2.6 - Packages roadmap

[Dmitriy Setrakyan]

Petr,

I think it was Denis who reworked the documentation. In any case, if you
see something lacking you can fix it.

Just to clarify, are you suggesting that you don't have to be root to run
the Ignite process after the package install?

D.

On Mon, Jun 4, 2018 at 9:31 PM, Petr Ivanov  wrote:

> >   1. Remove the requirement to run Ignite scripts as root. This will be a
> >   huge No in most environment and we should fix it.
>
>
> > There is already a ticket for point 1:
> > https://issues.apache.org/jira/browse/IGNITE-8695 <
> https://issues.apache.org/jira/browse/IGNITE-8695>
>
> 1. I am not the author of this part of instruction — someone, who
> completely reworked that section about running ignite as standalone process
> should also remove / rework the “require root permissions” part because in
> my version of documentation there was requirement to run as root, but
> requirement to run as ignite user (logining in into it with specified
> shell, because it is disabled by default — as it should be done for every
> service) due to packages’ postinstall scripts that assign ignite user
> permissions on all Apache Ignite directories.
>
>
> >   2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be
> >   executable without specifying the whole path name (not sure if it is
> >   already done or not)
>
> 2. We should not. Instead, we have to symlink all required scripts from
> bin/ to /usr/bin, providing changes to scripts it selves, so that they can
> be called from /usr/bin as if from $IGNITE_HOME ('readlink' command to find
> real symlink location).
>
>
> > I do remember the multi-package approach was suggested as a solution to
> > trim down the size of the binary that is hosted by ASF. Since now the
> > binaries are hosted in Bintray, do we still have that issue? If it's fine
> > to preload and keep big binaries in Bintray then I would suggest us to
> > postpone the multi-package activities until there is a real demand.
>
>
> 3. The multi-package approach was also suggested for more accurate
> architecture and more flexible updates. And working with smaller packages
> on development stage is too more reliable and easy.
> Yes, we can postpone it (for how long?) but I’d like to insist on proposed
> layout (and reimplement it rather quickly), because ta least it shows our
> packages as more mature (no one ships theirs software in single monolith
> package, especially in official repositories).
>
>
> > - Make sqlline.sh callable from command line (PATH). E.g. symlink it as
> > /usr/bin/sqlline-ignite, make sure it works.
> > - Fix control.sh and visor-cmd, expose them too.
>
> 4. See p.2. Indeed they need to be fixes and exposes 'by the book’.
>
>
> > - Allow specifying of JDK implementation and JDK arguments for Apache
> > Ignite startup. Preferably on per configuration basis.
>
> 5. Agree. We need some kind of 'setenv.sh’ for user-side JDK configuration.
>
>
> > - Allow adding-removing "modules" to classpath of Ignite - again,
> > preferably on per configuration basis. E.g. what happens if I want to
> turn
> > ON geospatial/
>
> 6. Agree, was thinking of it too, in form of 'a2enmod'-like utility for
> enabling / disabling optional libs and modules.
>
>
> > - [OPTIONAL] Ship Apache Ignite with a special config which only listens
> on
> > localhost. This is for lazy people who can get into trouble by installing
> > package without looking without security implications.
>
> 7. Arguable. Even if we create such config and put into delivery, there is
> no guarantee that user will read documentation about necessity of using
> this special config for security reasons.
> I would add BIG warning text to Ignite’s log about security implications
> of unprotected cluster.
>
>
> > With regards to splitting package, I think we could have a few of them
> > (a-i-core, a-i-doc, a-i-c++, a-i-.net) but I don't think we need to have
> a
> > half dozen of those right away. This was mostly realised as an
> antipattern.
>
> 8. I would at least removed benchmarks, docs and platforms from the core
> package.

Re: Apache Ignite 2.6 - Packages roadmap

[Petr Ivanov]

>   1. Remove the requirement to run Ignite scripts as root. This will be a
>   huge No in most environment and we should fix it.


> There is already a ticket for point 1:
> https://issues.apache.org/jira/browse/IGNITE-8695 
> 

1. I am not the author of this part of instruction — someone, who completely 
reworked that section about running ignite as standalone process should also 
remove / rework the “require root permissions” part because in my version of 
documentation there was requirement to run as root, but requirement to run as 
ignite user (logining in into it with specified shell, because it is disabled 
by default — as it should be done for every service) due to packages’ 
postinstall scripts that assign ignite user permissions on all Apache Ignite 
directories.


>   2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be
>   executable without specifying the whole path name (not sure if it is
>   already done or not)

2. We should not. Instead, we have to symlink all required scripts from bin/ to 
/usr/bin, providing changes to scripts it selves, so that they can be called 
from /usr/bin as if from $IGNITE_HOME ('readlink' command to find real symlink 
location).


> I do remember the multi-package approach was suggested as a solution to
> trim down the size of the binary that is hosted by ASF. Since now the
> binaries are hosted in Bintray, do we still have that issue? If it's fine
> to preload and keep big binaries in Bintray then I would suggest us to
> postpone the multi-package activities until there is a real demand.


3. The multi-package approach was also suggested for more accurate architecture 
and more flexible updates. And working with smaller packages on development 
stage is too more reliable and easy.
Yes, we can postpone it (for how long?) but I’d like to insist on proposed 
layout (and reimplement it rather quickly), because ta least it shows our 
packages as more mature (no one ships theirs software in single monolith 
package, especially in official repositories).


> - Make sqlline.sh callable from command line (PATH). E.g. symlink it as
> /usr/bin/sqlline-ignite, make sure it works.
> - Fix control.sh and visor-cmd, expose them too.

4. See p.2. Indeed they need to be fixes and exposes 'by the book’.


> - Allow specifying of JDK implementation and JDK arguments for Apache
> Ignite startup. Preferably on per configuration basis.

5. Agree. We need some kind of 'setenv.sh’ for user-side JDK configuration.


> - Allow adding-removing "modules" to classpath of Ignite - again,
> preferably on per configuration basis. E.g. what happens if I want to turn
> ON geospatial/

6. Agree, was thinking of it too, in form of 'a2enmod'-like utility for 
enabling / disabling optional libs and modules.


> - [OPTIONAL] Ship Apache Ignite with a special config which only listens on
> localhost. This is for lazy people who can get into trouble by installing
> package without looking without security implications.

7. Arguable. Even if we create such config and put into delivery, there is no 
guarantee that user will read documentation about necessity of using this 
special config for security reasons.
I would add BIG warning text to Ignite’s log about security implications of 
unprotected cluster.


> With regards to splitting package, I think we could have a few of them
> (a-i-core, a-i-doc, a-i-c++, a-i-.net) but I don't think we need to have a
> half dozen of those right away. This was mostly realised as an antipattern.

8. I would at least removed benchmarks, docs and platforms from the core 
package.

Re: Apache Ignite 2.6 - Packages roadmap

[Denis Magda]

There is already a ticket for point 1:
https://issues.apache.org/jira/browse/IGNITE-8695

--
Denis

On Mon, Jun 4, 2018 at 2:40 PM, Dmitriy Setrakyan 
wrote:

> Here is my list:
>
>1. Remove the requirement to run Ignite scripts as root. This will be a
>huge No in most environment and we should fix it.
>2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be
>executable without specifying the whole path name (not sure if it is
>already done or not)
>
> D.
>
> On Mon, Jun 4, 2018 at 7:43 AM, Petr Ivanov  wrote:
>
> > Igniters!
> >
> >
> > Apache Ignite 2.5 is released and for the first time in it’s history is
> > shipped in both RPM and DEB packages.
> > And, I think, it is time to discuss the future roadmap of Apache Ignite
> in
> > Linux packages initiative.
> >
> > For the first “feature” I would suggest splitting of the packages on
> > smaller parts (at least the same way it was prepare but declined in 2.5)
> —
> > we can continue discussion here.
> > Also it would be great to hear community thoughts about other possible
> > improvements of delivering Apache Ignite in packages.
>

Re: Apache Ignite 2.6 - Packages roadmap

[Dmitriy Setrakyan]

Here is my list:

   1. Remove the requirement to run Ignite scripts as root. This will be a
   huge No in most environment and we should fix it.
   2. Add Ignite "bin" folder to PATH, so all Ignite scripts will be
   executable without specifying the whole path name (not sure if it is
   already done or not)

D.

On Mon, Jun 4, 2018 at 7:43 AM, Petr Ivanov  wrote:

> Igniters!
>
>
> Apache Ignite 2.5 is released and for the first time in it’s history is
> shipped in both RPM and DEB packages.
> And, I think, it is time to discuss the future roadmap of Apache Ignite in
> Linux packages initiative.
>
> For the first “feature” I would suggest splitting of the packages on
> smaller parts (at least the same way it was prepare but declined in 2.5) —
> we can continue discussion here.
> Also it would be great to hear community thoughts about other possible
> improvements of delivering Apache Ignite in packages.

Re: Apache Ignite 2.6 - Packages roadmap

[Denis Magda]

Petr,

I do remember the multi-package approach was suggested as a solution to
trim down the size of the binary that is hosted by ASF. Since now the
binaries are hosted in Bintray, do we still have that issue? If it's fine
to preload and keep big binaries in Bintray then I would suggest us to
postpone the multi-package activities until there is a real demand.

--
Denis

On Mon, Jun 4, 2018 at 7:43 AM, Petr Ivanov  wrote:

> Igniters!
>
>
> Apache Ignite 2.5 is released and for the first time in it’s history is
> shipped in both RPM and DEB packages.
> And, I think, it is time to discuss the future roadmap of Apache Ignite in
> Linux packages initiative.
>
> For the first “feature” I would suggest splitting of the packages on
> smaller parts (at least the same way it was prepare but declined in 2.5) —
> we can continue discussion here.
> Also it would be great to hear community thoughts about other possible
> improvements of delivering Apache Ignite in packages.

Re: Apache Ignite 2.6 - Packages roadmap

[Ilya Kasnacheev]

Hello!

Here's my list of improvements for AI package:
- Make sqlline.sh callable from command line (PATH). E.g. symlink it as
/usr/bin/sqlline-ignite, make sure it works.
- Fix control.sh and visor-cmd, expose them too.
- Allow specifying of JDK implementation and JDK arguments for Apache
Ignite startup. Preferably on per configuration basis.
- Allow adding-removing "modules" to classpath of Ignite - again,
preferably on per configuration basis. E.g. what happens if I want to turn
ON geospatial/
- [OPTIONAL] Ship Apache Ignite with a special config which only listens on
localhost. This is for lazy people who can get into trouble by installing
package without looking without security implications.

With regards to splitting package, I think we could have a few of them
(a-i-core, a-i-doc, a-i-c++, a-i-.net) but I don't think we need to have a
half dozen of those right away. This was mostly realised as an antipattern.

Regards,

-- 
Ilya Kasnacheev

2018-06-04 17:43 GMT+03:00 Petr Ivanov :

> Igniters!
>
>
> Apache Ignite 2.5 is released and for the first time in it’s history is
> shipped in both RPM and DEB packages.
> And, I think, it is time to discuss the future roadmap of Apache Ignite in
> Linux packages initiative.
>
> For the first “feature” I would suggest splitting of the packages on
> smaller parts (at least the same way it was prepare but declined in 2.5) —
> we can continue discussion here.
> Also it would be great to hear community thoughts about other possible
> improvements of delivering Apache Ignite in packages.

Apache Ignite 2.6 - Packages roadmap

[Petr Ivanov]

Igniters!


Apache Ignite 2.5 is released and for the first time in it’s history is shipped 
in both RPM and DEB packages.
And, I think, it is time to discuss the future roadmap of Apache Ignite in 
Linux packages initiative.

For the first “feature” I would suggest splitting of the packages on smaller 
parts (at least the same way it was prepare but declined in 2.5) — we can 
continue discussion here.
Also it would be great to hear community thoughts about other possible 
improvements of delivering Apache Ignite in packages.