Can we change default configuration file then? So that both binary and package deliveries contained PDS turned on by default?
And what about Multicast Discovery? > On 25 Dec 2017, at 18:41, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > > I agree with Andrey. The product should be identical regardless of how you > download and install it. > > On Mon, Dec 25, 2017 at 7:18 AM, Andrey Gura <ag...@apache.org> wrote: > >> Hi, >> >> I think we should provide the same default configuration for all >> binary builds. From my point of view RPM/DEB/etc packages should use >> default configuration file like to standard binary release. >> >> On Mon, Dec 25, 2017 at 4:39 PM, Ilya Kasnacheev >> <ilya.kasnach...@gmail.com> wrote: >>> Hello Igniters! >>> >>> What's your take on enabling PDS in 2.4 in default config? This way we >>> could enable it in RPM build with easy heart. >>> >>> The rest of your answers seem spot on. I'll happily review your amended >>> patch when it is ready (later this week?) >>> >>> -- >>> Ilya Kasnacheev >>> >>> 2017-12-22 18:27 GMT+03:00 vveider <mr.wei...@gmail.com>: >>> >>>> Ilya Kasnacheev wrote >>>>> I have noticed that both spec and DEVNOTES are made to use tabs >> alongside >>>>> with spaces. I thought we are avoiding tabs? Please confirm that >> usage of >>>>> tabs is desired in this case. >>>> >>>> My fault - got used to editing such files in default vim. Fixed and >> updated >>>> vim settings to indent with spaces. >>>> >>>> >>>> Ilya Kasnacheev wrote >>>>> Maybe it's my CentOS but initially build will fail with the following >>>>> message, which I had to fix in spec >>>>> + cd 'apache-ignite-*' >>>>> /var/tmp/rpm-tmp.KwOoyl: line 34: cd: apache-ignite-*: No such file or >>>>> directory >>>> >>>> Strange error - shell expansion is not working. Anyway, replaced with >> more >>>> universal variant. >>>> >>>> >>>> Ilya Kasnacheev wrote >>>>> We absolutely should not inline configuration files (such as >>>>> default-config.xml) into build scripts. We should just copy over >>>>> default-config.xml from config/ to /etc, with dependencies if needed. >>>> >>>> Extracted corresponding sections into separate files. >>>> >>>> >>>> Ilya Kasnacheev wrote >>>>> I'm not sure PDS should be ON by default. Better provide it in >> examples >>>>> but disable by default. >>>> >>>> AFAIK, PDS is actively pushing forward and has to be enabled by default >> so >>>> that Ignite users start working with PDS from the very beginning. >>>> >>>> >>>> Ilya Kasnacheev wrote >>>>> I cannot comment on firewall rules validity, but firewall and service >>>>> configurations should be stored in sources, as files, supplied with >>>>> release (somewhere in packages/) and installed from there >>>> >>>> Unfortunately, I did not find any other way to open ports and multicast, >>>> except applying direct iptables rules though firewall-cmd -- so there >> can >>>> be >>>> no separate service firewall rules file (as can be found here: >>>> /usr/lib/firewalld/services). Applied rules from package go straight to >>>> /etc/firewalld/direct.xml. If we agree not to put Multicast-enabled by >>>> default configuration file and will stick to IP Discovery, I'll try to >>>> revise firewall configuration and create separate service firewall rules >>>> file (but, I guess, much later). >>>> >>>> >>>> Ilya Kasnacheev wrote >>>>> * sqlline.sh fails to connect initially, needs to be specified >>>>> jdbc:ignite:thin://localhost, then it works. I think that sqlline >> should >>>>> become available as /usr/bin/apache-ignite-sqlline for example, to be >> in >>>>> $PATH. And figure out how to connect by itself. >>>>> * ignitevisorcmd.sh becomes confused. first it scans >>>>> /usr/share/apache-ignite for configs, then it fails to write to >>>>> /usr/share/apache-ignite/work. We should consider how it can be fixed >> (a >>>>> symlink from /usr/share/apache-ignite/config to /etc/apache-ignite, >>>>> perhaps, and work dir in /tmp?), and made available as >>>>> /usr/bin/apache-ignite-visorcmd. >>>> >>>> The problem exists mainly because of sqlline.sh|ignitevisorcmd.sh >>>> unaware-of-package design and I see the following 3-step way to overcome >>>> this limitation. >>>> At first we hide this executables file in examples (As Iliya proposed). >>>> Secondly, I can design a patch, which can be applied during package >> build, >>>> so that those executables work normally form the package installation. >>>> And lastly, redesign them to be universal and compatible with all >> delivery >>>> methods. >>>> >>>> >>>> Ilya Kasnacheev wrote >>>>> Not everything should go into /usr/share. classpath libs belong to >>>>> /usr/lib. >>>> >>>> Moved libs to /usr/lib/apache-ignite and mapped to >>>> /usr/share/apache-ignite/libs (for backward compatibility). I guess >> later >>>> we >>>> have to think out of a solution to load libs directly from /usr/lib >> (along >>>> with configurations / logs / work / etc.) >>>> >>>> >>>> Ilya Kasnacheev wrote >>>>> We are building from binary package and not from sources. If it is >> used >>>> by >>>>> internal RPM building this is tolerable, but any distro or repository >>>> will >>>>> want to build from source. >>>> >>>> It's not an ordinary task to create "100% honest" package, so I guess we >>>> definitely won't make to 2.4 release. So I purpose include in the >> nearest >>>> release our package built from binary archive and do not supply sources >>>> package (as it is currently done in apache.org/dist for cassandra / >> hadoop >>>> or alike). And later design package build procedure, which includes >> getting >>>> sources from sources distribution, or even from Apache Ignite Git >>>> repository >>>> tag. >>>> >>>> >>>> Ilya Kasnacheev wrote >>>>> spec contains version (2.4.0) - will be needed to be changed for every >>>>> release. I'm not sure if it's possible to extract. >>>> >>>> Release procedure on TC is already has some task for project version >>>> update, >>>> so I guess it is not so difficult to update it accordingly (as it is >>>> currently done for C++ / .Net internal versions). >>>> >>>> >>>> Ilya Kasnacheev wrote >>>>> Package description may be improved. service description lacks '-' in >> "In >>>>> Memory". >>>> >>>> Fixed. >>>> >>>> >>>> So the only question to discuss (according Iliya's review) is whether to >>>> supply package with default-config.xml that has Multicast Discovery >> turned >>>> on or not? >>>> >>>> Also I'll appreciate any other comments concerning current package >> design. >>>> >>>> >>>> >>>> -- >>>> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >>>> >>
