Difference in load configuration for watch delay tests show how huge the
impact is. Even with random write scheduler grpc under http
server can only handle 500 KB with 2 seconds delay. On the other hand,
separate grpc server easily hits 10, 100 or even 1000 MB within 100 miliseconds.
Priority write scheduler that was used in most previous releases
is far worse than random one.
Tests configured to only 5 MB to avoid flakes and taking too long to fill
etcd.
Signed-off-by: Marek Siarkowicz <siarkowicz@google.com>
The issue is caused by hand-crafted protobuf message. The runtime.errorBody
defines two protobuf fields with same number. We need to upgrade the
version to fix it. Otherwise, the client side won't receive any errors
from server side because of panic.
```
mismatching field: runtime.errorBody.error, want runtime.errorBody.message
```
It can fix the cases
PASSES="build grpcproxy" CPU=4 RACE=true ./test -run TestV3CurlLeaseRevokeNoTLS
The original error is like:
```
v3_curl_lease_test.go:109: testV3CurlLeaseRevoke: prefix (/v3) endpoint (/kv/lease/revoke): error (read /dev/ptmx: input/output error (expected "etcdserver: requested lease not found", got ["curl: (52) Empty reply from server\r\n"])), wanted etcdserver: requested lease not found
v3_curl_lease_test.go:109: testV3CurlLeaseRevoke: prefix (/v3beta) endpoint (/kv/lease/revoke): error (read /dev/ptmx: input/output error (expected "etcdserver: requested lease not found", got ["curl: (52) Empty reply from server\r\n"])), wanted etcdserver: requested lease not found
```
The `Empty reply from server` is caused by panic and server recover it
but it doesn't have chance to reply to client.
Signed-off-by: Wei Fu <fuweid89@gmail.com>
Due to a duplicate call of clientConfigFromCmd, the move-leader command
would fail with "conflicting environment variable is shadowed by corresponding command-line flag".
Also in scenarios where no command-line flag was supplied.
Signed-off-by: Thomas Jungblut <tjungblu@redhat.com>
Etcd currently supports validating peers based on their TLS certificate's
CN field. The current best practice for creation and validation of TLS
certs is to use the Subject Alternative Name (SAN) fields instead, so that
a certificate might be issued with a unique CN and its logical
identities in the SANs.
This commit extends the peer validation logic to use Go's
`(*"crypto/x509".Certificate).ValidateHostname` function for name
validation, which allows SANs to be used for peer access control.
In addition, it allows name validation to be enabled on clients as well.
This is used when running Etcd behind an authenticating proxy, or as
an internal component in a larger system (like a Kubernetes master).
