mirror of
https://github.com/ceph/ceph
synced 2024-12-28 22:43:29 +00:00
023524a26d
One of our customers wants to verify the data safety of Ceph during scaling the cluster up, and the test case looks like: - keep checking the status of a speficied pg, who's up is [1, 2, 3] - add more osds: up [1, 2, 3] -> up [1, 4, 5], acting = [1, 2, 3], backfill_targets = [4, 5], pg is remapped - stop osd.2: up [1, 4, 5], acting = [1, 3], backfill_targets = [4, 5], pg is undersized - restart osd.2, acting will stay unchanged as 2 belongs to neither current up nor acting set, hence leaving the corresponding pg pinning undersized for a long time until all backfill targets completes It does not pose any critical problem -- we'll end up getting that pg back into active + clean, except that the long live DEGRADED warnings keep bothering our customer who cares about data safety more than any thing else. The right way to achieve the above goal is for: boost::statechart::result PeeringState::Active::react(const MNotifyRec& notevt) to check whether the newly booted node could be validly chosen for the acting set and request a new temp mapping. The new temp mapping would then trigger a real interval change that will get rid of the DEGRADED warning. Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn> Signed-off-by: Yan Jun <yan.jun8@zte.com.cn> |
||
|---|---|---|
| .. | ||
| archs | ||
| btrfs | ||
| cephfs | ||
| client | ||
| clusters | ||
| config | ||
| crontab | ||
| debug | ||
| distros | ||
| erasure-code | ||
| libceph | ||
| machine_types | ||
| mds | ||
| mon/bootstrap | ||
| msgr | ||
| nightlies | ||
| objectstore | ||
| objectstore_cephfs | ||
| overrides | ||
| packages | ||
| qa_scripts | ||
| rbd | ||
| releases | ||
| rgw_frontend | ||
| rgw_pool_type | ||
| standalone | ||
| suites | ||
| tasks | ||
| timezone | ||
| workunits | ||
| .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