featurebase/etcd
Seebs 98a7129464 use timeout when waiting for cluster state changes
We had this fail in CI once, and failing took 30 minutes because
we didn't have a timeout on this. This shouldn't ever fail, but
the fact that it did indicates that the fabled etcd failures
we've seen a couple of times were still capable of happening.
This will make that failure happen sooner and more clearly.

Also, log the cluster states (and possibly node states) while
waiting. But add a delay -- otherwise we can do this quite a few
times per millisecond. We use Logf so that, if you didn't use -v,
you see these reported only if the test fails, but if the test fails,
we'll say what happened.

It would probably be better to have a passive thing that can wait
for updates, because we're waiting on heartbeats. Missing: A way to
detect what's actually happening in the failure cases, which we
see only quite rarely.
2022-09-14 11:47:50 -05:00
..
config_gen.go simplify, streamline, and possibly debug embedded etcd 2022-07-21 11:42:35 -05:00
embed.go staticcheck is right, as usual 2022-09-14 11:47:50 -05:00
embed_test.go simplify, streamline, and possibly debug embedded etcd 2022-07-21 11:42:35 -05:00
enterprise_cluster.go Fb1463 no cluster build (#2100) 2022-06-09 12:32:46 -07:00
external.go staticcheck is right, as usual 2022-09-14 11:47:50 -05:00
external_test.go [FB-1598] Phase 0 of etcd extraction (#2169) 2022-07-29 15:27:04 -05:00
fake_test.go use timeout when waiting for cluster state changes 2022-09-14 11:47:50 -05:00
leasedkv.go [FB-1598] Phase 0 of etcd extraction (#2169) 2022-07-29 15:27:04 -05:00
leasedkv_test.go use timeout when waiting for cluster state changes 2022-09-14 11:47:50 -05:00
plg_cluster.go Fb1463 no cluster build (#2100) 2022-06-09 12:32:46 -07:00