If non-standard ssh-port is used, Geo-rep can be configured to use ssh port by using config option, the value should be in allowed port range and non negative. At present it can accept negative value and outside allowed port range which is incorrect. Many Linux kernels use the port range 32768 to 61000. IANA suggests it should be in the range 1 to 2^16 - 1, so keeping the same. $ gluster volume geo-replication master 127.0.0.1::slave config ssh-port -22 geo-replication config updated successfully $ gluster volume geo-replication master 127.0.0.1::slave config ssh-port 22222222 geo-replication config updated successfully This patch fixes the above issue and have added few validations around this in test cases. Change-Id: I9875ab3f00d7257370fbac6f5ed4356d2fed3f3c Fixes: bz#1792276 Signed-off-by: Sunny Kumar <sunkumar@redhat.com>
Problem: The bug[1] addresses issue of data inconsistency when handling RENAME with existing destination. This fix requires some performance tuning considering this issue occurs in heavy rename workload. Solution: If distribution count for master volume is one do not verify op's on master and go ahead with rename. The performance improvement with this patch can only be observed if master volume has distribution count one. [1]. https://bugzilla.redhat.com/show_bug.cgi?id=1694820 fixes: bz#1753857 Change-Id: I8e9bcd575e7e35f40f9f78b7961c92dee642f47b Signed-off-by: Sunny Kumar <sunkumar@redhat.com>
Background: The processed changelogs are archived each month in a single tar file. The default format is "archive_YYYYMM.tar" which is specified as "%%Y%%m" in configuration file. Problem: The created changelog archive file didn't have corresponding year and month. It created as "archive_%Y%m.tar" on python2 only systems. Cause and Fix: Geo-rep expects "%Y%m" after the ConfigParser reads it from config file. Since it was "%%Y%%m" in config file, geo-rep used to get correct value "%Y%m" in python3 and "%%Y%%m" in python2 which is incorrect. The fix can be to use "%Y%m" in config file but that fails in python3. So the fix is to use "RawConfigParser" in geo-rep and use "%Y%m". This works both in python2 and python3. Change-Id: Ie5b7d2bc04d0d53cd1769e064c2d67aaf95d557c fixes: bz#1741890 Signed-off-by: Kotresh HR <khiremat@redhat.com>
Problem: When 'use_tarssh' is set to true, it exits with successful message but the default 'rsync' was used as sync-engine. The new config 'sync-method' is not allowed to set from cli. Analysis and Fix: The 'use_tarssh' config is deprecated with new config framework and 'sync-method' is the new config to choose sync-method i.e. tarssh or rsync. This patch fixes the 'sync-method' config. The allowed values are tarssh and rsync. Change-Id: I0edb0319cad0455b29e49f2f08a64ce324735e84 fixes: bz#1707686 Signed-off-by: Kotresh HR <khiremat@redhat.com>
'%' needs special handling in config and also removed duplicate misspelled 'changelog-archive-format' config. Updates: #411 Change-Id: I33621a62bdf5f781ee62e6cedec0c2df3f5d70cf Signed-off-by: Kotresh HR <khiremat@redhat.com>
1. '--ignore-mising-args' option for rsync is not being used even though the rsync version is greater than 3.1.0. Fixed the same. 2. '--existing' option for rsync is also not being used. Fixed the same. 3. geo-rep config fails to set rsync-options as the value contains '--'. Interestingly, python argsparse treats the value with '--' (e.g., --ignore-missing-args) as option. But when passed with something like --value=--ignore-missing-args, it succeeds. Fixed the same. Change-Id: Iaeb838acaff1c2920fee9c7f920c99edce13a0a1 Signed-off-by: Kotresh HR <khiremat@redhat.com> fixes: bz#1629561
Autmatic gfid conflict resolution needs to be disabled during failover/failback as it might lead to data loss in the following scenario. 1. Master went down without syncing directory "dir1" to slave. 2. When slave is failed over to master, if a new file is written inside "dir1", creating dir1 again if not present, "dir1" ends up with different gfid on original slave. 3. When original master is up and failed back, due to automatic gfid conflict resolution, "dir1" present in original master is deleted losing all files and only new file created on original slave is restored. Hence during failover/failback, automatic gfid conflict resolution should be disabled. So in these cases, appropriate decision is taken. fixes: bz#1622076 Signed-off-by: Kotresh HR <khiremat@redhat.com> Change-Id: I433616f5d3e13d4b6eb675475bd554ca34928573
This is part of the reason why we use autoconf (i.e. configure). For an ordinary clone+autogen.sh+configure SBIN_DIR is /usr/local/sbin; for an rpm or dpkg build it will be /usr/sbin. I wonder how many more are lurking in our sources? /usr/libexec is one that frequently bites us on Debian and Ubuntu, which don't have /usr/libexec. (But it's all Linux, right?) See https://bugzilla.redhat.com/show_bug.cgi?id=1601532 Reported-by: lohmaier+rhbz@gmail.com Change-Id: I6523894416cc06236ea1f99529efd36e957bd98e updates: bz#1193929 Signed-off-by: Kaleb S. KEITHLEY <kkeithle@redhat.com>
JSON output of `config-get` command now returns in the following
format
{
"name": CONFIG_NAME,
"value": CONFIG_VALUE,
"default_value": DEFAULT_VALUE, # Only if modified == true
"configurable": true|false,
"modified": true|false
}
Change-Id: I6193de48cd33655df7ecef5a0d83d7cb147089cf
Fixes: #361
Signed-off-by: Aravinda VK <avishwan@redhat.com>
Once Geo-replication is started, it runs Gluster commands to get Volume
info from Master and Slave. With this patch, Georep can get Volume info
from Conf file if `--use-gconf-volinfo` argument is specified to monitor
Create a config(Or add to the config if exists) with following fields
[vars]
master-bricks=NODEID:HOSTNAME:PATH,..
slave-bricks=NODEID:HOSTNAME,..
master-volume-id=
slave-volume-id=
master-replica-count=
master-disperse_count=
Note: Exising Geo-replication is not affected since this is activated
only when `--use-gconf-volinfo` is passed while spawning `gsyncd
monitor`
Tiering support is not yet added since Tiering + Glusterd2 is still
under discussion.
Fixes: #396
Change-Id: I281baccbad03686c00f6488a8511dd6db0edc57a
Signed-off-by: Aravinda VK <avishwan@redhat.com>