Bug #40112
closedmon: rados/multimon tests fail with clock skew
0%
Description
See
http://pulpito.ceph.com/sage-2019-05-30_21:14:09-rados:multimon-master-distro-basic-smithi/
or
http://pulpito.ceph.com/sage-2019-06-03_14:22:18-rados:multimon-master-distro-basic-smithi/
http://pulpito.ceph.com/sage-2019-06-03_14:24:56-rados:multimon-nautilus-distro-basic-smithi/
The second variant, where we don't see the SKEW failure, appears to be caused because the ceph setup command to set the crush tunables takes foreeever due to no quorum, but eventually the clocks correct themselves and then the job proceeds (probably NTP)?
The underlying problem appears to be that mons can't form quorum if there is too much skew, which prevents a meaningful test.
whenever mon.b is the rank 0 mon.
Updated by Sage Weil almost 5 years ago
- Status changed from 12 to Pending Backport
- Backport set to nautilus
Updated by Nathan Cutler almost 5 years ago
- Copied to Backport #40228: nautilus: mon: rados/multimon tests fail with clock skew added
Updated by Nathan Cutler over 4 years ago
- Has duplicate Bug #38893: RuntimeError: expected MON_CLOCK_SKEW but got none added
Updated by Nathan Cutler over 4 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved".
Updated by Nathan Cutler about 4 years ago
- Backport changed from nautilus to nautilus, mimic
Updated by Nathan Cutler about 4 years ago
- Status changed from Resolved to Pending Backport
Updated by Nathan Cutler about 4 years ago
- Copied to Backport #44908: mimic: mon: rados/multimon tests fail with clock skew added
Updated by Nathan Cutler almost 4 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".