ceph/qa
Sridhar Seshasayee d20f57000b osd/OSD: Log slow ops/types to cluster logs
In addition to logging slow ops in mon and osd specific log files,
re-introduce logging the same information along with slow op type
details to cluster logs as well. The objective is to make debugging
slow ops easier.

Modify the log whitelisting string to "slow request" within qa suites in
order to make the search for the new warning log message within the
cluster log successful. This should not cause any issue as it's a
substring of the earlier string.

Fixes: https://tracker.ceph.com/issues/43975
Signed-off-by: Sridhar Seshasayee <sseshasa@redhat.com>
2020-02-19 14:31:48 +05:30
..
archs
btrfs
cephfs
client
clusters qa/suites/rados/cephadm: deploy prometheus.a 2020-02-13 13:59:36 -06:00
config
crontab qa/tests: reduced runs for nautilus, added runs for octopus 2020-02-11 08:37:15 -08:00
debug
distros qa/suites/rados/cephadm: move ubuntu_18.04_podman to shared location 2020-02-07 17:49:52 -06:00
erasure-code
libceph
machine_types qa/tests: reduced runs for nautilus, added runs for octopus 2020-02-11 08:37:15 -08:00
mds
mon/bootstrap
msgr
nightlies
objectstore
objectstore_cephfs
overrides
packages
qa_scripts
rbd
releases
rgw_frontend
rgw_pool_type
standalone
suites osd/OSD: Log slow ops/types to cluster logs 2020-02-19 14:31:48 +05:30
tasks osd/OSD: Log slow ops/types to cluster logs 2020-02-19 14:31:48 +05:30
timezone
workunits Merge pull request #33219 from dillaman/wip-44066-2 2020-02-13 16:20:52 +02:00
.gitignore
CMakeLists.txt
find-used-ports.sh
loopall.sh
Makefile
README
run_xfstests_qemu.sh
run_xfstests-obsolete.sh
run_xfstests.sh
run-standalone.sh
runallonce.sh
runoncfuse.sh
runonkclient.sh
setup-chroot.sh
tox.ini
valgrind.supp

ceph-qa-suite
-------------

clusters/    - some predefined cluster layouts
suites/      - set suite

The suites directory has a hierarchical collection of tests.  This can be
freeform, but generally follows the convention of

  suites/<test suite name>/<test group>/...

A test is described by a yaml fragment.

A test can exist as a single .yaml file in the directory tree.  For example:

 suites/foo/one.yaml
 suites/foo/two.yaml

is a simple group of two tests.

A directory with a magic '+' file represents a test that combines all
other items in the directory into a single yaml fragment.  For example:

 suites/foo/bar/+
 suites/foo/bar/a.yaml
 suites/foo/bar/b.yaml
 suites/foo/bar/c.yaml

is a single test consisting of a + b + c.

A directory with a magic '%' file represents a test matrix formed from
all other items in the directory.  For example,

 suites/baz/%
 suites/baz/a.yaml
 suites/baz/b/b1.yaml
 suites/baz/b/b2.yaml
 suites/baz/c.yaml
 suites/baz/d/d1.yaml
 suites/baz/d/d2.yaml

is a 4-dimensional test matrix.  Two dimensions (a, c) are trivial (1
item), so this is really 2x2 = 4 tests, which are

  a + b1 + c + d1
  a + b1 + c + d2
  a + b2 + c + d1
  a + b2 + c + d2

A directory with a magic '$' file represents a test where one of the other
items is chosen randomly. For example,

suites/foo/$
suites/foo/a.yaml
suites/foo/b.yaml
suites/foo/c.yaml

is a single test.  It will be either a.yaml, b.yaml or c.yaml.  This can be
used in conjunction with the '%' file in other directories to run a series of
tests without causing an unwanted increase in the total number of jobs run.

Symlinks are okay.

The teuthology code can be found in https://github.com/ceph/teuthology.git