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

polkadot-parachain-bin: small cosmetics and improvements #4666

Merged
merged 9 commits into from
Jun 14, 2024

Conversation

serban300
Copy link
Contributor

@serban300 serban300 commented Jun 1, 2024

Related to: #5

A couple of cosmetics and improvements related to polkadot-parachain-bin:

  • Adding some convenience traits in order to avoid declaring long duplicate bounds
  • Specifically check if the runtime exposes AuraApi when executing start_lookahead_aura_consensus()
  • Some fixes for the RelayChainCli. Details in the commits description

@serban300 serban300 self-assigned this Jun 1, 2024
@serban300 serban300 added R0-silent Changes should not be mentioned in any release notes T0-node This PR/Issue is related to the topic “node”. labels Jun 1, 2024
@serban300 serban300 force-pushed the polkadot-parachain-service-2 branch from 8531cce to 8905ab5 Compare June 3, 2024 08:10
@@ -251,6 +235,11 @@ where
let client = params.client.clone();
let backend = params.backend.clone();

let info = backend.blockchain().info();
if !client.runtime_api().has_basic_apis(info.genesis_hash) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I am not sure if this works atm, some of these system chains were initially run as Shell and might not have the aura api in the initial blocks afaik.

Alternatively, the changes in https://github.com/paritytech/polkadot-sdk/tree/kiz-omni-node is one way to keep this crate mostly unchanged, and only enable the omni-node when an unknonw chain-spec is given.

We could subsume that branch here.

Copy link
Contributor

Choose a reason for hiding this comment

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

Specifically, see how I have replaced enum Runtime::Default with Runtime::Omni, and all new codes are constrained to this code path.

Copy link
Contributor

Choose a reason for hiding this comment

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

Tbh, solely because of these legacy decisions in system chains and then requiring special code such as WaitForAuraConsensus, I am in favour of not touching polkadot-parachain, and starting a fresh new omni-node crate, keep polkadot-parachain unchanged, and drop-in replace it once done. @bkchr iirc you had some reservations about this, wdyt?

Copy link
Contributor Author

@serban300 serban300 Jun 3, 2024

Choose a reason for hiding this comment

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

Good point. You're right. It wasn't working when syncing system parachains. Removed the has_basic_apis() check and also the check for AuraUnincludedSegmentApi.

Maybe we can add has_basic_apis() back somewhere after upgrading from shell. I don't know. But probably it would also require some refactoring in order to make it fit. We can revisit it in the future. For the moment this PR remains mainly refactoring with the only functional change being the added check for AuraApi inside start_lookahead_aura_consensus().

Copy link
Contributor

Choose a reason for hiding this comment

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

I am not sure if this works atm, some of these system chains were initially run as Shell and might not have the aura api in the initial blocks afaik.

But that only applies to asset hub runtimes, which is why they use the separate start_asset_hub_lookahead_node() entry point. So, might it still be okay to keep that check in the general start_generic_aura_lookahead_node()?

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 problem is that we would have to perform this check somewhere after new_partial() was called. And I don't think there is a generic way to do this now just for start_asset_hub_lookahead_node(). I think it would be better to do it in a future PR together with some more refactoring.

@serban300 serban300 marked this pull request as ready for review June 3, 2024 11:01
@serban300 serban300 changed the title [Draft] Add extra startup checks to polkadot-parachain-bin Add extra startup checks to polkadot-parachain-bin Jun 3, 2024
@serban300 serban300 marked this pull request as draft June 4, 2024 07:07
@serban300 serban300 changed the title Add extra startup checks to polkadot-parachain-bin [Draft] Add extra startup checks to polkadot-parachain-bin Jun 4, 2024
@serban300 serban300 changed the title [Draft] Add extra startup checks to polkadot-parachain-bin [WIP] Add extra startup checks to polkadot-parachain-bin Jun 4, 2024
@serban300 serban300 force-pushed the polkadot-parachain-service-2 branch from 8c16afb to 1e5aa34 Compare June 10, 2024 07:43
@serban300 serban300 force-pushed the polkadot-parachain-service-2 branch from 71b551d to 9c6ea89 Compare June 11, 2024 08:10
- Parse the `RelayChainCli` before starting the runner. This is helpful
  in case of executing `polkadot-parachain ... -- --help` or if the
  relay chain command is malformed
- Set `no_binary_name(true)`
- Use the same `base_path` as the parachain
  This will lead to using paths like for example:
  - /tmp/substratexaqpXv/chains/bridge-hub-kusama
  - /tmp/substratexaqpXv/chains/kusama
  instead of:
  - /tmp/substratexaqpXv/chains/bridge-hub-kusama
  - /tmp/substratexaqpXv/polkadot/chains/kusama
For consistency. For example `start_node()` uses
`FullNetworkConfiguration::<_, _, Net>::new(&parachain_config.network)`
@serban300 serban300 force-pushed the polkadot-parachain-service-2 branch from 9c6ea89 to 6bfdebd Compare June 11, 2024 10:45
@serban300 serban300 changed the title [WIP] Add extra startup checks to polkadot-parachain-bin [WIP] polkadot-parachain-bin: small cosmetics and improvements Jun 12, 2024
@serban300 serban300 changed the title [WIP] polkadot-parachain-bin: small cosmetics and improvements polkadot-parachain-bin: small cosmetics and improvements Jun 12, 2024
@serban300 serban300 marked this pull request as ready for review June 12, 2024 07:18
@@ -0,0 +1,25 @@
[package]
Copy link
Member

Choose a reason for hiding this comment

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

This entire crate is not really needed. If you want to have these aliases, declare them in the polkadot parachain binary.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

My intention with this crate is to slowly start moving generic logic into it. It would be the equivalent of the cumulus-service crate in Kian's omni-node PR: #3597 . I started with defining these aliases here and then I would like to slowly start moving parts of the start_node logic, while also refactoring them. So that then we could reuse this logic for polkadot-parachain, the parachain template, the solochain template, and also for the parachain teams to be able to build custom parachains with it. WDYT ?

Copy link
Member

Choose a reason for hiding this comment

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

They are not required. I already assumed that you wanted to do this. For now we should focus on the omni node and node some non existing builder. So, either remove or move to the binary directly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, done.

Copy link
Contributor

Choose a reason for hiding this comment

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

They are not required. I already assumed that you wanted to do this. For now we should focus on the omni node and node some non existing builder. So, either remove or move to the binary directly.

@bkchr I don't agree your opinion here, please hear me out:

In order to get out of the technical debt of the node side, we inevitably need cumulus-service or omni-node-common or similar to exist.

A lot of the code between the 3 templates + polkadot-parachain is shared, but in reality is is copy-pasted because we don't have a shared crate. And reusable compoents (like, "build an aura import queue for me please") are the long hanging fruit way to make improvements to this.

I personally think it makes for a good learning objective for @serban300 to start thinking about such refactors. The time he would spend doing this refactor is well worth it + he can demonstrate that he can already simplify the code of the templates as well with the same traits and helpers that he has added to this PR.

I think your intention in asking to revert these refactors is speeding up the release of the omni-node itself, but I don't think this will speed it up by much. @serban300 and I already have another branch ready with release-able changes, which will come right after this PR. The main reason I am holding back on the above branch is to do more testing with more teams etc, not coding or engineering effort.

I won't insist on revering the changes in this PR per-se, but I hope we have a consensus to encourage such refactors in the coming PRs related to omni-node, as it serves our long term goals.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would like to merge this PR in order to then continue the work related to renaming polkadot-parachain on top of it. But let's continue this discussion and use the conclusion in the following PRs

cumulus/polkadot-parachain/src/cli.rs Outdated Show resolved Hide resolved
cumulus/polkadot-parachain/src/service.rs Show resolved Hide resolved
Copy link
Contributor

@s0me0ne-unkn0wn s0me0ne-unkn0wn left a comment

Choose a reason for hiding this comment

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

Nice cleanup, thank you! I'd still run a manual test to make sure the asset hub is functional and can sync from scratch, just in case.

@serban300
Copy link
Contributor Author

Nice cleanup, thank you! I'd still run a manual test to make sure the asset hub is functional and can sync from scratch, just in case.

Thank you ! Yes, syncing polkadot-asset-hub from scratch. Seems ok so far, but letting it fully sync.

@serban300
Copy link
Contributor Author

Nice cleanup, thank you! I'd still run a manual test to make sure the asset hub is functional and can sync from scratch, just in case.

Thank you ! Yes, syncing polkadot-asset-hub from scratch. Seems ok so far, but letting it fully sync.

Synced polkadot-asset-hub and also polkadot-bridge-hub partially and everything worked correctly

@serban300 serban300 added this pull request to the merge queue Jun 14, 2024
Merged via the queue into paritytech:master with commit 7f7f5fa Jun 14, 2024
158 of 160 checks passed
@serban300 serban300 deleted the polkadot-parachain-service-2 branch June 14, 2024 06:57
Ank4n pushed a commit that referenced this pull request Jun 14, 2024
Related to: #5

A couple of cosmetics and improvements related to
`polkadot-parachain-bin`:

- Adding some convenience traits in order to avoid declaring long
duplicate bounds
- Specifically check if the runtime exposes `AuraApi` when executing
`start_lookahead_aura_consensus()`
- Some fixes for the `RelayChainCli`. Details in the commits description
TarekkMA pushed a commit to moonbeam-foundation/polkadot-sdk that referenced this pull request Aug 2, 2024
…h#4666)

Related to: paritytech#5

A couple of cosmetics and improvements related to
`polkadot-parachain-bin`:

- Adding some convenience traits in order to avoid declaring long
duplicate bounds
- Specifically check if the runtime exposes `AuraApi` when executing
`start_lookahead_aura_consensus()`
- Some fixes for the `RelayChainCli`. Details in the commits description
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
R0-silent Changes should not be mentioned in any release notes T0-node This PR/Issue is related to the topic “node”.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants