-
Notifications
You must be signed in to change notification settings - Fork 680
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
polkadot-parachain-bin
: small cosmetics and improvements
#4666
Conversation
8531cce
to
8905ab5
Compare
@@ -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) { |
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 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.
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.
Specifically, see how I have replaced enum Runtime::Default
with Runtime::Omni
, and all new codes are constrained to this code path.
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.
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?
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.
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()
.
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 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()
?
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.
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.
polkadot-parachain-bin
polkadot-parachain-bin
polkadot-parachain-bin
polkadot-parachain-bin
polkadot-parachain-bin
polkadot-parachain-bin
8c16afb
to
1e5aa34
Compare
71b551d
to
9c6ea89
Compare
- 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(¶chain_config.network)`
9c6ea89
to
6bfdebd
Compare
polkadot-parachain-bin
polkadot-parachain-bin
: small cosmetics and improvements
polkadot-parachain-bin
: small cosmetics and improvementspolkadot-parachain-bin
: small cosmetics and improvements
@@ -0,0 +1,25 @@ | |||
[package] |
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.
This entire crate is not really needed. If you want to have these aliases, declare them in the polkadot parachain binary.
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.
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 ?
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.
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.
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.
Ok, done.
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.
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.
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 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
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.
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.
And move logic to polakdot-parachain
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 |
7f7f5fa
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
…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
Related to: #5
A couple of cosmetics and improvements related to
polkadot-parachain-bin
:AuraApi
when executingstart_lookahead_aura_consensus()
RelayChainCli
. Details in the commits description