add MemberDowngradeUpgrade failpoint #19125
Conversation
|
Skipping CI for Draft Pull Request. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted filessee 25 files with indirect coverage changes @@ Coverage Diff @@
## main #19125 +/- ##
==========================================
- Coverage 68.87% 68.80% -0.08%
==========================================
Files 420 420
Lines 35649 35649
==========================================
- Hits 24554 24527 -27
- Misses 9674 9699 +25
- Partials 1421 1423 +2 Continue to review full report in Codecov by Sentry.
|
Signed-off-by: Siyuan Zhang <[email protected]>
siyuanfoundation
force-pushed
the
downgrade-robust-2
branch
from
c6e3a18 to
6f8d37f
Compare
|
/cc @ahrtr @serathius |
5% flakly on github or prow might be acceptable, because the test environment is out of our control, but in your local environment, it is still a little concerning. Overall the PR looks good. Thanks for the nice work. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ahrtr, siyuanfoundation The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| return nil | ||
| } | ||
|
|
||
| func verifyVersion(t *testing.T, clus *e2e.EtcdProcessCluster, member e2e.EtcdProcess, expectedServerVersion, expectedClusterVersion *semver.Version) error { |
There was a problem hiding this comment.
Probably we can move this function into test/framework/e2e/utils.go, so that it can be reused by other downgrade or migrate related e2e test cases.
Please read https://github.com/etcd-io/etcd/blob/main/CONTRIBUTING.md#contribution-flow.
#17118
The MemberDowngradeUpgrade failpoint first downgrades all members, and upgrades some members. This is to test no robustness issue during the whole downgrade-upgrade process, which can be stopped at any point.
Tested locally with
There is a little flakiness due to reasons unrelated to what the test wants to do, like a server fails to start. But that's mainly because we are stopping and restarting the servers many times. I think <5% is probably acceptable.