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: IGNITE-7107 Apache Ignite RPM packages
Date Mon, 25 Dec 2017 15:51:12 GMT
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 <dsetrakyan@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 <agura@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.kasnacheev@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.weider@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/
>>>> 
>> 


Mime
View raw message