mirror of
https://github.com/status-im/consul.git
synced 2025-01-09 21:35:52 +00:00
20caa4f744
When the envoy healthy panic threshold was explicitly disabled as part of L7 traffic management it changed how envoy decided to load balance to endpoints in a cluster. This only matters when envoy is in "panic mode" aka "when you have a bunch of unhealthy endpoints". Panic mode sends traffic to unhealthy instances in certain circumstances. Note: Prior to explicitly disabling the healthy panic threshold, the default value is 50%. What was happening is that the test harness was bringing up consul the sidecars, and the service instances all at once and sometimes the proxies wouldn't have time to be checked by consul to be labeled as 'passing' in the catalog before a round of EDS happened. The xDS server in consul effectively queries /v1/health/connect/s2 and gets 1 result, but that one result has a 'critical' check so the xDS server sends back that endpoint labeled as UNHEALTHY. Envoy sees that 100% of the endpoints in the cluster are unhealthy and would enter panic mode and still send traffic to s2. This is why the test suites PRIOR to disabling the healthy panic threshold worked. They were _incorrectly_ passing. When the healthy panic threshol is disabled, envoy never enters panic mode in this situation and thus the cluster has zero healthy endpoints so load balancing goes nowhere and the tests fail. Why does this only affect the test suites for envoy 1.8.0? My guess is that https://github.com/envoyproxy/envoy/pull/4442 was merged into the 1.9.x series and somehow that plays a role. This PR modifies the bats scripts to explicitly wait until the upstream sidecar is healthy as measured by /v1/health/connect/s2?passing BEFORE trying to interrogate envoy which should make the tests less racy.
48 lines
1.4 KiB
Bash
48 lines
1.4 KiB
Bash
#!/usr/bin/env bats
|
|
|
|
load helpers
|
|
|
|
@test "s1 proxy admin is up on :19000" {
|
|
retry_default curl -f -s localhost:19000/stats -o /dev/null
|
|
}
|
|
|
|
@test "s2 proxy admin is up on :19001" {
|
|
retry_default curl -f -s localhost:19001/stats -o /dev/null
|
|
}
|
|
|
|
@test "s1 proxy listener should be up and have right cert" {
|
|
assert_proxy_presents_cert_uri localhost:21000 s1
|
|
}
|
|
|
|
@test "s2 proxy listener should be up and have right cert" {
|
|
assert_proxy_presents_cert_uri localhost:21001 s2
|
|
}
|
|
|
|
@test "s2 proxy should be healthy" {
|
|
assert_service_has_healthy_instances s2 1
|
|
}
|
|
|
|
@test "s1 upstream should be able to connect to s2" {
|
|
run retry_default curl -s -f -d hello localhost:5000
|
|
[ "$status" == "0" ]
|
|
[ "$output" == "hello" ]
|
|
}
|
|
|
|
@test "s1 proxy should send trace spans to zipkin/jaeger" {
|
|
# Send traced request through upstream. Debug echoes headers back which we can
|
|
# use to get the traceID generated (no way to force one I can find with Envoy
|
|
# currently?)
|
|
run curl -s -f -H 'x-client-trace-id:test-sentinel' localhost:5000/Debug
|
|
|
|
echo "OUTPUT $output"
|
|
|
|
[ "$status" == "0" ]
|
|
|
|
# Get the traceID from the output
|
|
TRACEID=$(echo $output | grep 'X-B3-Traceid:' | cut -c 15-)
|
|
|
|
# Get the trace from Jaeger. Won't bother parsing it just seeing it show up
|
|
# there is enough to know that the tracing config worked.
|
|
run retry_default curl -s -f "localhost:16686/api/traces/$TRACEID"
|
|
}
|