Add zombienet integration - #307
Conversation
With this we could use generic Anyway I think that as an intermediate step we could move presets to the runtimes, and keep
As reference, some example work of moving presets from binary to runtime is provided here: paritytech/polkadot-sdk#3996 |
bkchr
left a comment
There was a problem hiding this comment.
Left only nitpicks.
For a first integration it is good, but also doesn't do that much :D
| log::trace!("{:?}", e); | ||
| if let subxt::Error::Rpc(subxt::error::RpcError::ClientError(inner)) = e { | ||
| log::trace!("inner: {}", inner.to_string()); | ||
| if inner.to_string().contains("i/o error") { |
There was a problem hiding this comment.
Yes, I'm not super happy with this. Maybe @jsdw can help with a better approach to check if the inner error is related to i/o.
Thx!
There was a problem hiding this comment.
Because somebody can plug in an arbitrary RPC client, we end up with this Box<dyn std::error::Error + Send + Sync + 'static> type to store errors from them. If you know which RPC client is used, you can try to cast that into the relevant error.
In the usual case, the error will be a jsonrpsee_core::ClientError, so in that case you could do something like:
if let Ok(client_error) = inner.downcast::<jsonrpsee_core::ClientError> {
if matches!(client_error, ClientError::Transport(_)) {
// ...
}
}It's not much less ugly though in the end!
Not sure if this applies for you, but in Subxt the way that we wait for the node to be ready for connections is to wait for it to log that it's listening for them, ie https://github.com/paritytech/subxt/blob/ec7cea0acb59cdffb281aacd86a62c33514331e6/testing/substrate-runner/src/lib.rs#L191-L198 (that waits for a couple of "legacy" strings that nodes don't emit now too, which we can prob remove at this point).
| let config = small_network().unwrap(); | ||
|
|
||
| // spawn | ||
| let now = Instant::now(); | ||
| let network = spawn_fn(config).await.unwrap(); | ||
| let elapsed = now.elapsed(); | ||
| log::info!("🚀🚀🚀🚀 network deployed in {:.2?}", elapsed); | ||
|
|
||
| let alice = network.get_node("alice").unwrap(); |
There was a problem hiding this comment.
Where can I find the names of the nodes? How do I know if a node belongs to a parachain or the relay chain?
There was a problem hiding this comment.
The config came from small_network and I placed there for reuse in other tests, but could be better to each test have it's own config in the same file to easily find the nodes/paras. I can change if you are agree.
Thx!
There was a problem hiding this comment.
I mean I saw where it came from, but even there I don't see the names of the nodes :D
There was a problem hiding this comment.
Ahh oks, in the sdk you have to set the name of the node with a like like this
.with_node(|node| node.with_name("alice"))but we can make more explicit as const to be easily find with a quick look. wdyt?
There was a problem hiding this comment.
.with_node(|node| node.with_name("alice"))
But you don't do this here anywhere in the code? Or am I blind?
There was a problem hiding this comment.
One thing that is weird is that you call it with_node and for the parachain with_collator, while for the relay chain the node is probably a validator?
There was a problem hiding this comment.
Thanks for the feedback! 🙌
Yes, the naming could be confusing. Both method with_node and with_collator return a NodeConfigBuilder that by default is validator (this is also confusing because for nodes of a parachain means that we pass the flag --collator).
Maybe is better to just have with_node with the default _role_ set to ROLE::AUTHORITY and you can change to full with node.role(ROLE::FULL)
So, this way is more clear and use the same wording you see in the logs of the client. wdyt?
Thx!
There was a problem hiding this comment.
So, this way is more clear and use the same wording you see in the logs of the client. wdyt?
Or just call them with_validator, with_node and with_collator. Probably the least confusing one. Otherwise I would go with with_node and require that you make it a validator/collator (but the argument against this being that you almost never need a normal full node in the tests)
There was a problem hiding this comment.
Yes, I think is more explicit and will cause less confusion have those 3 methods 👍.
Thanks again for the feedback!
update: tracking here
Co-authored-by: Bastian Köcher <git@kchr.de>
| @@ -562,7 +595,7 @@ dependencies = [ | |||
| "frame-support", | |||
| "kusama-emulated-chain", | |||
| "parachains-common", | |||
| "sp-core", | |||
| "sp-core 29.0.0", | |||
There was a problem hiding this comment.
@pepoviola is it possible to deduplicate the dependencies so that we don't have 2 versions of polkadot-sdk crates?
There was a problem hiding this comment.
or is it coming from subxt?
There was a problem hiding this comment.
Yes, we can align the version of sp-core. There is any reason why we are using 29.0.0 here since the latest release is 32.0.0?
Thanks!!
There was a problem hiding this comment.
it's probably fine to leave it as is for now. the versions will be upgraded when we update the runtumes to the next polkadot-sdk release
There was a problem hiding this comment.
Yea its fine as long as we dont have duplicated versions in the runtimes themselves.
|
Ping @bkchr, can we merge this one? Thx! |
There was a problem hiding this comment.
Why do we still have one extra Cargo.lock file?
There was a problem hiding this comment.
We shouldn't, let me delete this one. Thanks for the feedback.
|
/merge |
|
Enabled Available commands
For more information see the documentation |
Hi 👋 , this pr add a very small smoke test as PoC of using zombienet-sdk with the runtimes repo. The idea is to explore the integration and add more assertions (metrics, logs, etc) and complex scenarios in the future (e.g: test upgrades, mix node's versions, etc).
This test use a set of env vars that allow you to specify the images and the provider to use:
POLKADOT_IMAGE(default: docker.io/parity/polkadot:latest)CUMULUS_IMAGE(default: docker.io/parity/polkadot-parachain:latest)ZOMBIE_PROVIDER(default: Docker)And needs to have the
chain-spec-generatorbinary as part of yourPATH, any feedback is welcome :)Also worth notice that the
chain-spec-generatortool is compiling all the runtimes, and would be good to only compile the needed ones (polkadot in this case), we can add some feature-gate logic or we can also move _ presets_ to runtimes (ping @michalkucharczyk ).Thanks!