Apache Ignite 2.6 - Packages roadmap

[vveider]

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.

[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 <[hidden email]>:

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

[dmagda]

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 <[hidden email]> 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.

[dsetrakyan]

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 <[hidden email]> 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.

[dmagda]

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 <[hidden email]>
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 <[hidden email]> 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.
>

[vveider]

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

[dsetrakyan]

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 <[hidden email]> 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.

[vveider]

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 <[hidden email]> 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 <[hidden email]> 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.

[dsetrakyan]

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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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.
>
>

[vveider]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
>> 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 <[hidden email]> 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.
>>
>>

[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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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 <[hidden email]>
> >> 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 <[hidden email]>
> 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.
> >>
> >>
>
>

--
Sergey Kozlov
GridGain Systems
www.gridgain.com

[dsetrakyan]

On Tue, Jun 5, 2018 at 1:54 PM, Sergey Kozlov <[hidden email]> 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.

[dsetrakyan]

On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov <[hidden email]> 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.

[dmagda]

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 <[hidden email]>
wrote:

> On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov <[hidden email]> 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.
>

[vveider]

Denis,


I’ll look into it


On Wed, 6 Jun 2018 at 19:17, Denis Magda <[hidden email]> 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 <[hidden email]>
> wrote:
>
> > On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov <[hidden email]>
> 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.
> >
>

[dmagda]

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 <[hidden email]> wrote:

> Denis,
>
>
> I’ll look into it
>
>
> On Wed, 6 Jun 2018 at 19:17, Denis Magda <[hidden email]> 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 <[hidden email]
> >
> > wrote:
> >
> > > On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov <[hidden email]>
> > 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.
> > >
> >
>

[vveider]

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 <[hidden email]> 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 <[hidden email]> wrote:
>
> > Denis,
> >
> >
> > I’ll look into it
> >
> >
> > On Wed, 6 Jun 2018 at 19:17, Denis Magda <[hidden email]> 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 <
> [hidden email]
> > >
> > > wrote:
> > >
> > > > On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov <[hidden email]>
> > > 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.
> > > >
> > >
> >
>

[dsetrakyan]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> wrote:
> >
> > > Denis,
> > >
> > >
> > > I’ll look into it
> > >
> > >
> > > On Wed, 6 Jun 2018 at 19:17, Denis Magda <[hidden email]> 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 <
> > [hidden email]
> > > >
> > > > wrote:
> > > >
> > > > > On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov <[hidden email]>
> > > > 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.
> > > > >
> > > >
> > >
> >
>

[vveider]

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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> > wrote:
> > >
> > > > Denis,
> > > >
> > > >
> > > > I’ll look into it
> > > >
> > > >
> > > > On Wed, 6 Jun 2018 at 19:17, Denis Magda <[hidden email]> 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 <
> > > [hidden email]
> > > > >
> > > > > wrote:
> > > > >
> > > > > > On Tue, Jun 5, 2018 at 12:12 PM, Petr Ivanov <
> [hidden email]>
> > > > > 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.
> > > > > >
> > > > >
> > > >
> > >
> >
>

[dsetrakyan]

On Wed, Jun 6, 2018 at 10:40 PM, Peter Ivanov <[hidden email]> 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.