Description of problem:
server.statedump-path is the path where statedumps are stored,
by default it is /var/run/gluster. And can be set to any valid
directory path. It was observed that server.statedump-path was
also accepting file, non-existent file and non-existent paths
as well. And statedump command was successful even when
statedumps with all the invalid paths.
a. A file
b. A non-existent path
Solution:
Added a validation function in gluster-volume-set.c which will
allow volume set to success if it's a valid directory
and in all other cases, volume set should fail.
Fixes: bz#1787122
Change-Id: Ia66e2b3d35f23efc5444c829928779a79d827b42
Signed-off-by: yatipadia <ypadia@redhat.com>
Signed-off-by: Sanju Rakonde <srakonde@redhat.com>
1. Both read and write tests required writing first. Either just
writing (write test) or write and then read (read test).
So the code is now unified.
2. There's no reason to read zeros from /dev/zero. Just use a
CALLOC'ed buffer.
I don't think we should read and write zeros, but I did not change
the code yet (I think compression and/or dedup will offset results)
It appears neither read-perf nor write-perf were tested, so added
basic tests for them.
Change-Id: I24b1f249fa0335ed652a8982e99c0687d940230e
updates: bz#1193929
Signed-off-by: Yaniv Kaul <ykaul@redhat.com>
Based on the proposal to remove few features as they are not
actively maintained [1], removing stripe translator from the
build. Also make sure there are no regression tests involving
stripe translator.
[1] https://lists.gluster.org/pipermail/gluster-users/2018-July/034400.html
Note that this patch aims at removing the translator from build, and
a followup patch is needed to remove the code from repository.
Updates: bz#1364707
Change-Id: I235b305338f138e29e9f30cba65bc0dadbebbbd5
Signed-off-by: Amar Tumballi <amarts@redhat.com>
Problem : When gluster volume remove-brick is executed with out any option, it
defaults to force commit which results in data loss.
Fix : remove-brick can not be executed with out explicit option, user needs to
provide the option in the command line else the command will throw back an usage
error.
Earlier usage : volume remove-brick <VOLNAME> [replica <COUNT>] <BRICK> ...
[start|stop|status|commit|force]
Current usage : volume remove-brick <VOLNAME> [replica <COUNT>] <BRICK> ...
<start|stop|status|commit|force>
Change-Id: I2a49131f782a6c0dcd03b4dc8ebe5907999b0b49
BUG: 1077682
Signed-off-by: Atin Mukherjee <amukherj@redhat.com>
Reviewed-on: http://review.gluster.org/7292
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Shyamsundar Ranganathan <sam.somari@gmail.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Framework for writing test cases to be submitted with patches.
This framework and the test cases get exercised by Jenkins in
the pre-commit regression test. Jenkins is configured to give
a +1 verified vote only if the regression test passes without
failures (which includes test cases added/changed by the patch
being tested)
Every patch should include a test case (either extensions/changes
to existing test cases or add new ones, as appropriate). The test
case should be part of the same commit so that both code and
test case get reviewed together.
Test cases added are cumulative. Every new patch gets
tested against its own test case and every test case previously
added.
A lot of new commits in the near future will be pure test cases
(with no code change) which will get added in "catch up" mode.
The tool used for implementing test cases is 'prove', and the
framework itself is modeled similar to the POSIX compliance
filesystem test suite.
Under the top level directory, a new directory named 'tests/'
is added. This contains top level classifier directories and
framework files/scripts.
Functionality tests should be created under a classifier directory
below 'tests/'. For e.g:
tests/basic/mount.t
tests/performance/write-behind.t
Bugs which get fixed should include a test case script named
by the bug id, so that we are guaranteed any new change will
not bring the issue back. For e.g:
tests/bugs/bug-123456.t
Triggering of regression tests in Jenkins is manual at this point
as we do not want the entire test suite to run against every
revision of a patch while it is still in the review/resubmit cycle.
Signed-off-by: Anand Avati <avati@redhat.com>
Change-Id: I8078244619135ccaba38e068925f8ca85141055a
BUG: 764966
Signed-off-by: Anand Avati <avati@redhat.com>
Reviewed-on: http://review.gluster.org/4101
Tested-by: Gluster Build System <jenkins@build.gluster.com>
