* e2e: Extract Docker-specific functionality
Extract Docker-specific functionality and put it behind an interface
that should hopefully, without too much modification, allow us to
implement a Digital Ocean-based infrastructure provider.
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Thread contexts through all potentially long-running functions
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Drop the "API" from interface/struct/var naming
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Simplify function returns
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Rename GenerateConfig to Setup to make it more generic
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Consolidate all infra functions into a single interface
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Localize linter directives
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Look up and use complete node in ShowNodeLogs and TailNodeLogs calls
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Restructure infra provider API into a separate package
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Rename interface again
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Rename exec functions for readability
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Relocate staticcheck lint directive
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Remove staticcheck lint directive
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Make testnet infra struct private
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Only pass testnetDir to Cleanup function
Signed-off-by: Thane Thomson <connect@thanethomson.com>
This pull requests adds the protocol buffer field for the `ABCI.VoteExtensionsEnableHeight` parameter. This proto field is threaded throughout all of the relevant places where consensus params are used and referenced.
This PR also adds validation of the consensus param updates. Previous consensus param changes didn't depend on _previous_ versions of the params, so this change adds a method for validating against the old params as well.
closes: #8453
We stopped testing these configurations a while ago, and it doesn't
really make sense to allow nodes to run in this configuration. This
drops support for non-blocksync nodes and cleans up the
configuration/tests accordingly.
Closes: #6908
This tweaks the connectivity of test configurations, in hopes that more will be viable.
Additionally reduces the prevalence of testing the legacy mempool.
This code hasn't been battle tested, and seems to have grown
increasingly flaky int tests. Given our general direction of reducing
queue complexity over the next couple of releases I think it makes
sense to remove it.
A few notes:
- this is not all the deletion that we can do, but this is the most
"simple" case: it leaves in shims, and there's some trivial
additional cleanup to the transport that can happen but that
requires writing more code, and I wanted this to be easy to review
above all else.
- This should land *after* we cut the branch for 0.35, but I'm
anticipating that to happen soon, and I wanted to run this through
CI.
I observed a couple of problems with the generator in some recent tests:
- there were a couple of hybrid test cases which did not have any
legacy nodes (randomness and all.) I change the probability to
produce more reliable results.
- added options to the generation to be able to add a max (to
compliment the earlier min) number of nodes for local testing.
- added an option to support reversing the sort order so "more
complex" networks were first, as well as tweaked some of the point
values.
- this refactored the generators cli parsing to be a bit more clear.
The previous implemention of hybrid set testing, which was entirely my
own creation, was a bit peculiar, and I think this probably clears thins up.
The previous implementation had far fewer legacy nodes in hybrid
networks, *and* also for some reason that I can't quite explain,
caused a test case to fail.
This is just a configuration change to default to using the new stack
unless explicitly disabled (e.g. `UseLegacy`) this renames the
configuration value and makes the configuration logic more clear.
The legacy option is good to retain as a fallback if the new stack has
issues operationally, but we should make sure that most of the time
we're using the new stack.
In the transaction load generator, the e2e test harness previously distributed load randomly to hosts, which was a source of test non-determinism. This change distributes the load generation to the different nodes in the set in a round robin fashion, to produce more reliable results, but does not otherwise change the behavior of the test harness.
also
- replace `MaxReconnectAttempts`, `ReadWait`, `WriteWait` and `PingPeriod` options with `WSOptions` in `WSClient` (rpc/jsonrpc/client/ws_client.go).
- set default write wait to 10s for `WSClient`(rpc/jsonrpc/client/ws_client.go)
- unexpose `WSEvents`(rpc/client/http.go)
Closes#6162
* Don't use state sync for nodes starting at initial height.
* Also remove stopped containers when cleaning up.
* Start nodes in order of startAt, mode, name to avoid full nodes starting before their seeds.
* Tweak network waiting to avoid halts caused by validator changes and perturbations.
* Disable most tests for seed nodes, which aren't always able to join consensus.
* Disable `blockchain/v2` due to known bugs.
In #5488 the E2E testnet generator changed to setting explicit `StartAt` heights for initial nodes. This broke the runner, which expected all initial nodes to have `StartAt: 0`, as well as validator set scheduling in the generator. Testnet loading now normalizes initial nodes to have `StartAt: 0`.
This also tweaks waiting for misbehavior heights to only use an additional wait if there actually is any misbehavior in the testnet, and to output information when waiting.
Closes#5291. Adds a randomized testnet generator. Nightly CI job will be submitted separately. A few of the testnets can be a bit flaky, even after disabling known-faulty behavior and making minor tweaks, and the larger networks may be too resource-intensive to run in CI - this will be optimized separately.
