Backport of PR #16822, commits f7e488dc9262685d6624755e0d3bb0a655863248,
67f17166bf2ba337dafb8e0ea8eea5f74a990767,
and f7ff898fd6c2d6dbb54278343073aa4fa5f46a03.
Co-authored-by: Benjamin Wang <benjamin.wang@broadcom.com>
Signed-off-by: Ivan Valdes <ivan@vald.es>
Finish backporting the remaining functions from the original backport
from PR #15620.
Backport of commit 65add8cec44b32682e59d2596a592038bac90dcd.
Co-authored-by: Marek Siarkowicz <siarkowicz@google.com>
Signed-off-by: Ivan Valdes <ivan@vald.es>
Fixes the incorrect backport of WaitLeader, as spawnJsonCmd receives an
expected output string as an argument, which wasn't provided in the
first backport implementation.
Original backport of commit 371179e29208f690477c85fc552e7c824a66f87e from
PR #17398.
Signed-off-by: Ivan Valdes <ivan@vald.es>
Add Etcdctl function to etcdProcess interface, and implement it in
etcdServerProcess, which is used by WaitMembersForLeader.
Define Etcdctl's Status function, that is used by WaitMembersForLeader
too.
Signed-off-by: Ivan Valdes <ivan@vald.es>
value is selected empirically after spot checking some logs of flaky workflows
fixes: https://github.com/etcd-io/etcd/issues/15634
Signed-off-by: Bogdan Kanivets <bkanivets@apple.com>
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>
