ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Petr Ivanov <mr.wei...@gmail.com>
Subject Re: Apache Ignite 2.6 - Packages roadmap
Date Tue, 05 Jun 2018 19:12:32 GMT
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 <dsetrakyan@apache.org> 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 <mr.weider@gmail.com> 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 <dsetrakyan@apache.org>
>> 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 <mr.weider@gmail.com> 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.
>> 
>> 


Mime
View raw message