Skip to content
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 zombienet integration #307

Merged

Conversation

pepoviola
Copy link
Contributor

  • Does not require a CHANGELOG entry

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-generator binary as part of your PATH, any feedback is welcome :)


Also worth notice that the chain-spec-generator tool 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!

@michalkucharczyk
Copy link
Contributor

michalkucharczyk commented May 10, 2024

or we can also move _ presets_ to runtimes

With this we could use generic chain-spec-builder to build chain-specs.
But there is still open question how to handle the rest of chain-spec (e.g. chain-name, id, tokenDecimals). Providing them in command line every time the tool is used will be inconvenient. As trivial/naive solution bunch of utility scripts could be provided. Any thoughts on this? Unfortunately I don't have good ideas on this. We would also need a way to provide production specs.

Anyway I think that as an intermediate step we could move presets to the runtimes, and keep chain-spec-builder in this rep:

  • without any dependencies on runtime crates
  • and maybe reusing this little lib which is part of generic tool.

As reference, some example work of moving presets from binary to runtime is provided here: paritytech/polkadot-sdk#3996

Copy link
Contributor

@bkchr bkchr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left only nitpicks.

For a first integration it is good, but also doesn't do that much :D

integration-tests/zombienet/src/lib.rs Outdated Show resolved Hide resolved
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") {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is also quite hacky :P

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

integration-tests/zombienet/src/lib.rs Outdated Show resolved Hide resolved
integration-tests/zombienet/src/lib.rs Outdated Show resolved Hide resolved
integration-tests/zombienet/src/lib.rs Outdated Show resolved Hide resolved
.github/workflows/test.yml Outdated Show resolved Hide resolved
integration-tests/zombienet/Cargo.toml Outdated Show resolved Hide resolved
integration-tests/zombienet/Cargo.toml Outdated Show resolved Hide resolved
Comment on lines +11 to +19
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();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where can I find the names of the nodes? How do I know if a node belongs to a parachain or the relay chain?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean I saw where it came from, but even there I don't see the names of the nodes :D

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.with_node(|node| node.with_name("alice"))

But you don't do this here anywhere in the code? Or am I blind?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fuck I'm blind 🤦 🤦

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)

Copy link
Contributor Author

@pepoviola pepoviola May 16, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think is more explicit and will cause less confusion have those 3 methods 👍.
Thanks again for the feedback!
update: tracking here

integration-tests/zombienet/tests/smoke.rs Outdated Show resolved Hide resolved
integration-tests/zombienet/Cargo.toml Outdated Show resolved Hide resolved
integration-tests/zombienet/Cargo.toml Outdated Show resolved Hide resolved
@pepoviola
Copy link
Contributor Author

ping @eskimor / @ordian, can you also please review this one (we need 3 rank 3 reviews).
Thanks!!

@@ -562,7 +595,7 @@ dependencies = [
"frame-support",
"kusama-emulated-chain",
"parachains-common",
"sp-core",
"sp-core 29.0.0",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pepoviola is it possible to deduplicate the dependencies so that we don't have 2 versions of polkadot-sdk crates?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or is it coming from subxt?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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!!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea its fine as long as we dont have duplicated versions in the runtimes themselves.

@pepoviola
Copy link
Contributor Author

Ping @bkchr, can we merge this one? Thx!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we still have one extra Cargo.lock file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't, let me delete this one. Thanks for the feedback.

@bkchr
Copy link
Contributor

bkchr commented May 22, 2024

/merge

@fellowship-merge-bot
Copy link
Contributor

Enabled auto-merge in Pull Request

Available commands
  • /merge: Enables auto-merge for Pull Request
  • /merge cancel: Cancels auto-merge for Pull Request
  • /merge help: Shows this menu

For more information see the documentation

@fellowship-merge-bot fellowship-merge-bot bot enabled auto-merge (squash) May 22, 2024 13:59
@fellowship-merge-bot fellowship-merge-bot bot merged commit 65e23d8 into polkadot-fellows:main May 22, 2024
37 checks passed
@michalkucharczyk michalkucharczyk mentioned this pull request Jun 12, 2024
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants