-
Notifications
You must be signed in to change notification settings - Fork 4
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
Add support for generic clients #49
Conversation
6ba9f16
to
d0a089c
Compare
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.
Sorry for the super lateness on this, but it looks really good overall! Mostly small comments
src/lib.rs
Outdated
@@ -314,3 +322,13 @@ pub fn check_directory(path: &Path, description: &str) -> Result<(), Box<dyn std | |||
} | |||
Ok(()) | |||
} | |||
|
|||
pub fn validate_docker_image(image: String) -> Result<(), String> { |
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: can this take a &str
instead since it's validating from the command line?
src/main.rs
Outdated
.default_value("0") | ||
.help("Wait for `delay-start` seconds after all validators are deployed to deploy client. | ||
Use case: If client needs to connect to a specific node, but that node hasn't fully deployed yet | ||
the client may no be able to resolve the node's endpoint. `--delay-start` is used to wait so |
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.
micro-nit
the client may no be able to resolve the node's endpoint. `--delay-start` is used to wait so | |
the client may not be able to resolve the node's endpoint. `--delay-start` is used to wait so |
src/main.rs
Outdated
.arg( | ||
Arg::with_name("client_duration_seconds") | ||
.long("client-duration-seconds") | ||
.takes_value(true) | ||
.default_value("7500") | ||
.value_name("SECS") | ||
.help("Client Config. Seconds to run benchmark, then exit"), | ||
) | ||
.arg( | ||
Arg::with_name("client_wait_for_n_nodes") | ||
.long("client-wait-for-n-nodes") | ||
.short('N') | ||
.takes_value(true) | ||
.value_name("NUM") | ||
.help("Client Config. Optional: Wait for NUM nodes to converge"), | ||
.help("Seconds to run benchmark, then exit"), | ||
) |
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.
Is this arg used if you're not using bench-tps
or generic-client
? If not, it might be clearer to keep it under the subcommands, even if it's repeated.
d0a089c
to
2aa6101
Compare
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.
Looks great, thanks for explaining everything!
Bring your own client
Requested feature from Brennan
Bench-tps client is currently the only client you can run in validator lab. This PR allows you to deploy any client.
I took the approach of requiring the user to containerize their own client. It decouples the specific client logic with the validator lab logic.
I am not 100% sold on how this is implemented. For example, user has to build their own container image for their client and any accounts you need have to be built directly into the container image. Also, if you need cluster specific args, you'll have to modify the validator-lab code to add those cluster specific values as environment variables. For example, see
SHRED_VERSION
example in the READMEBut figured I'd open a PR in case you all had thoughts.
(also i changed
ValidatorType
toNodeType
sinceClient
is a valid type but it is not a validator)Next PR would be to deploy just clients. So you could spin up say 20 clients that all target testnet for example.