]> git.apps.os.sepia.ceph.com Git - ceph-ci.git/commit
osd/PeeringState: restart peering on any previous down acting member coming back
authorxie xingguo <xie.xingguo@zte.com.cn>
Fri, 14 Feb 2020 10:26:52 +0000 (18:26 +0800)
committerYan Jun <yan.jun8@zte.com.cn>
Fri, 21 Feb 2020 09:52:52 +0000 (17:52 +0800)
commit023524a26d7e12e7ddfc3537582b1a1cb03af69e
treefd2f9270ac03a311f1baaecc36273899e7c7ab72
parentc406ffa79bace428861bdffc8c51a424d2d05f5e
osd/PeeringState: restart peering on any previous down acting member coming back

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>
qa/standalone/osd/repeer-on-acting-back.sh [new file with mode: 0755]
src/osd/PeeringState.cc
src/osd/PeeringState.h