-
Notifications
You must be signed in to change notification settings - Fork 323
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Testground tooling #2456
feat: Testground tooling #2456
Conversation
Co-authored-by: CHAMI Rachid <[email protected]>
…b.com/celestiaorg/celestia-app into evan/multi-validator-genesis-creation
Codecov Report
@@ Coverage Diff @@
## evan/multi-validator-genesis-creation #2456 +/- ##
=========================================================================
+ Coverage 20.61% 20.76% +0.15%
=========================================================================
Files 131 136 +5
Lines 15270 15624 +354
=========================================================================
+ Hits 3148 3245 +97
- Misses 11820 12055 +235
- Partials 302 324 +22
|
the test can run a 3 validator network atm, but there are still a few minor but blocking bugs left. I'll add a way to sync before the "planning" stage to handle those bugs, then we should be good write the larger tests 🤞 |
|
||
var _ = Configurator(ConnectRandom(1)) | ||
|
||
func ConnectRandom(numPeers int) Configurator { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these are deleted in the ubounded block size iirc, but current tests support them
@rootulp do you have any clue why the ledger test is breaking? its breaking locally as well, but wasn't breaking a few commits ago |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I skipped reviewing the code in test/testground/* and instead focused on the celestia-app portions
package testground | ||
|
||
const ( | ||
Version uint64 = 420420420 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[nit] Version could use a GoDoc that explains why this number looks crazy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved in 93cb5d4
default: | ||
return v1.SquareSizeUpperBound | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO this thread shouldn't block this PR and instead we should create a new issue for this.
Go doesn't have exhaustive checking (like Rust) but I don't understand why silently defaulting to an old version is preferable over a panic
. I see the options as:
Current
func SquareSizeUpperBound(v uint64) int {
switch v {
case testground.Version:
return testground.SquareSizeUpperBound
// There is currently only a single square size upper bound.
default:
return v1.SquareSizeUpperBound
}
Proposal
func SquareSizeUpperBound(v uint64) int {
switch v {
case testground.Version:
return testground.SquareSizeUpperBound
case v1.Version:
return v1.SquareSizeUpperBound
case v2.Version:
return v2.SquareSizeUpperBound
default:
panic(fmt.Sprintf("unsupported version %v", v))
}
}
const ( | ||
Version uint64 = 420420420 | ||
SquareSizeUpperBound int = 512 | ||
SubtreeRootThreshold int = 64 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[question] related to https://github.com/celestiaorg/celestia-app/pull/2456/files#r1417502424
why define this constant if it is never used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved in 93cb5d4
we should probably do the same for v2
test/testground/README.md
Outdated
// Role is the interface between a testground test entrypoint and the actual | ||
// test logic. Testground creates many instances and passes each instance a | ||
// configuration from the plan and manifest toml files. From those | ||
// configurations a Role is created for each node, and the three methods below | ||
// are ran in order. | ||
type Role interface { | ||
// Plan is the first function called in a test by each node. It is | ||
// responsible for creating the genesis block, configuring nodes, and | ||
// starting the network. | ||
Plan(ctx context.Context, runenv *runtime.RunEnv, initCtx *run.InitContext) error | ||
// Execute is the second function called in a test by each node. It is | ||
// responsible for running any experiments. This is phase where commands are | ||
// sent and received. | ||
Execute(ctx context.Context, runenv *runtime.RunEnv, initCtx *run.InitContext) error | ||
// Retro is the last function called in a test by each node. It is | ||
// responsible for collecting any data from the node and/or running any | ||
// retrospective tests or benchmarks. | ||
Retro(ctx context.Context, runenv *runtime.RunEnv, initCtx *run.InitContext) error | ||
} | ||
|
||
var _ Role = (*Leader)(nil) | ||
|
||
var _ Role = (*Follower)(nil) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[optional] This Go code may become stale with respect to the Role
interface defined in test/testground/network.go
. We may remove the code and replace with a permalink.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
resolved in 93cb5d4
There's a weird bug where this test is failing consistently in ci bug not locally. It also doesn't make any sense, since it was just passing and the commit that broke it only added docs and removed an usused var |
@@ -119,7 +124,8 @@ func DefaultConfig() *Config { | |||
WithAppConfig(DefaultAppConfig()). | |||
WithAppOptions(DefaultAppOptions()). | |||
WithAppCreator(cmd.NewAppServer). | |||
WithSupressLogs(true) | |||
WithSuppressLogs(true). | |||
WithConsensusParams(DefaultConsensusParams()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
setting the default consensus params here fixes the failing test, which apparently we aren't doing doing on main! This doesn't fail on main, because we don't actually have a test that checks that the version is updated but now we do here
Overview
This is a refactor of the celestia-app tests in test-infra. The refactor focuses on further removing boiler plate and using our existing testing utilities for devUX, but also allows for more elaborate test scenarios and data collection.
Testground requires that each node is responsible for intializing, operating, performing tests, and collecting data on itself. To do this this refactor adds a new
Role
interface, where we define specific roles thatPlan
,Execute
, andRetro
. The first test case makes use of the interface to define aLeader
andFollower
, where we can have theLeader
generate all the keys, configs, genesis, etc duringPlan
and then publishes that data to allFollowers
, which use their respective configuration to start their node. After execution of the test, eachRole
can run arbitraryRetro
logic over the data produced or collected during the test run.The first experiment is mean to add as similar environment to mainnet as possible. We will use this as a base control case for an upcoming PR that adds the unbounded blocksize test
Please see the README for more info and diagrams
closes #2033 blocking celestiaorg/celestia-core#945
Checklist