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