-
Notifications
You must be signed in to change notification settings - Fork 9.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add failover test cases #13737
Add failover test cases #13737
Conversation
Codecov Report
@@ Coverage Diff @@
## main #13737 +/- ##
==========================================
- Coverage 72.78% 72.63% -0.15%
==========================================
Files 467 467
Lines 38287 38287
==========================================
- Hits 27867 27811 -56
- Misses 8617 8669 +52
- Partials 1803 1807 +4
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thank you.
ce9db35
to
833b0e9
Compare
Resolved all the comments. We can ignore the |
833b0e9
to
9b6681f
Compare
All test are green now after retriggering the pipeline. |
|
||
// Launch an etcd cluster with 3 members | ||
t.Logf("Launching an etcd cluster with 3 members [%s]", tc.name) | ||
clus := integration2.NewCluster(t, &integration2.ClusterConfig{Size: 3, ClientTLS: &integration2.TestTLSInfo}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this TLS config match what is expected in production w.r.t. validity of serving certificates and distinct hostnames (or is it using localhost / identical loopback IPs for all members)? I have memories of the etcd client not handling TLS validation on failover correctly (e.g. #10911) and wanted to make sure we're actually exercising the scenario
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a good point, thanks for pointing out this.
It's using localhost & 127.0.0.1 (see below). The e2e & integration tests are supposed to be automatically executed in pipeline, so all etcd members are always running on the same host?
Probably we need to think about how to run & test etcd in an environment which is close to production? cc @ptabor @serathius @spzala
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Subject Key Identifier:
F4:B1:45:B9:C4:18:A5:74:3B:5A:C9:21:10:60:4F:6F:5F:EF:12:64
X509v3 Authority Key Identifier:
keyid:29:26:2B:F4:ED:D9:18:F5:60:74:CE:00:7A:C0:E6:FF:1C:C8:BC:A0
X509v3 Subject Alternative Name:
DNS:localhost, IP Address:127.0.0.1
Fix 13707
Add failover test to cover the following two scenarios,
cc @ptabor @serathius @spzala