ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Kozlov <skoz...@gridgain.com>
Subject Re: Apache Ignite 2.6 - Packages roadmap
Date Tue, 05 Jun 2018 20:54:54 GMT
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 <mr.weider@gmail.com> 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 <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.
> >>
> >>
>
>


-- 
Sergey Kozlov
GridGain Systems
www.gridgain.com

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message