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 simplifications and deduplications #4916

Merged
merged 14 commits into from
Jul 9, 2024

Conversation

serban300
Copy link
Contributor

@serban300 serban300 commented Jul 1, 2024

polkadot-parachain simplifications and deduplications

Details in the commit messages. Just copy-pasting the last commit description since it introduces the biggest changes:

    Implement a more structured way to define a node spec
    
    - use traits instead of bounds for `rpc_ext_builder()`,
      `build_import_queue()`, `start_consensus()`
    - add a `NodeSpec` trait for defining the specifications of a node
    - deduplicate the code related to building a node's components /
      starting a node

The other changes are much smaller, most of them trivial and are isolated in separate commits.

@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 Jul 1, 2024
@serban300 serban300 self-assigned this Jul 1, 2024
@serban300 serban300 force-pushed the polkadot-parachain-refactoring branch from c1d4390 to 0a291dc Compare July 1, 2024 10:50
@serban300 serban300 force-pushed the polkadot-parachain-refactoring branch from 0a291dc to 0121d3c Compare July 1, 2024 11:31
@serban300 serban300 changed the title [WIP] polkadot-parachain simplifications and deduplications polkadot-parachain simplifications and deduplications Jul 1, 2024
@serban300 serban300 marked this pull request as ready for review July 1, 2024 11:34
Copy link
Contributor

@kianenigma kianenigma left a comment

Choose a reason for hiding this comment

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

Looks broadly good, would be great to get this in and on top of it build support for manual-seal.

@acatangiu acatangiu requested a review from a team July 2, 2024 11:41
- use traits instead of bounds for `rpc_ext_builder()`,
  `build_import_queue()`, `start_consensus()`
- add a `NodeSpec` trait for defining the specifications of a node
- deduplicate the code related to building a node's components /
  starting a node
Copy link
Contributor

@skunert skunert left a comment

Choose a reason for hiding this comment

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

In general the new structure seems reasonable to me.

One use-case I was thinking about during the review is temporary or experimental features. One example is a --experimental-use-slot-based command line flag that will enable a new experimental collator.

Previously I was just adding this flag and based on it choosing the closure to start consensus, here. With the model proposed here stuff like this gets a bit harder, I would need to implement StartConsensus and a new NodeSpec that uses it.

One reasonable addition would be to have some struct like extra_args (name is shitty 😬 ) that gets added to the parameters of the associated types.

@@ -31,6 +31,15 @@ use sp_blockchain::{Error as BlockChainError, HeaderBackend, HeaderMetadata};
/// A type representing all RPC extensions.
pub type RpcExtension = jsonrpsee::RpcModule<()>;

pub trait BuildRpcExtensions<Client, Backend, Pool> {
Copy link
Contributor

Choose a reason for hiding this comment

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

IMO we can move the impls of this trait to this module too. The impls of this trait mostly do nothing and just call the methods of this module. And instantiate the FullDeps struct which I think we can get rid of.

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, looks better. And service.rs is pretty big anyway, so it helps to move some of the logic. Done.

cumulus/polkadot-parachain/src/command.rs Outdated Show resolved Hide resolved
Copy link
Member

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

Generally the idea of getting rid off the macros is a good idea. However, I think we can simplify stuff even more.

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

One use-case I was thinking about during the review is temporary or experimental features. One example is a --experimental-use-slot-based command line flag that will enable a new experimental collator.

Previously I was just adding this flag and based on it choosing the closure to start consensus, here. With the model proposed here stuff like this gets a bit harder, I would need to implement StartConsensus and a new NodeSpec that uses it.

One reasonable addition would be to have some struct like extra_args (name is shitty 😬 ) that gets added to the parameters of the associated types.

Yes, sounds good. The extra_args struct should be the right solution in this case. But I wouldn't add it now since it would just be an unused empty struct. I would add it together with the --experimental-use-slot-based logic. If you merge #4097 first, I can then add it here when I fix the conflicts. Or if this PR gets merged first, please can you add it in #4097 ?

@serban300
Copy link
Contributor Author

@kianenigma @skunert @bkchr thanks for the reviews ! I addressed all your comments. Can you please take another look when you have time ?

_backend: Arc<ParachainBackend>,
_pool: Arc<sc_transaction_pool::FullPool<Block, ParachainClient<RuntimeApi>>>,
) -> sc_service::error::Result<RpcExtension> {
Ok(RpcExtension::new(()))
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this useful in any code path? I can't imagine it being used, although I have not fully looked at the PR.

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, it's used for the shell runtime. Although I don't know. Maybe we could use the BuildParachainRpcExtensions there as well ?

Copy link
Contributor

Choose a reason for hiding this comment

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

Nah I think the Shell doesn't have all the runtime apis that are needed. So it makes sense to have this for now. Later on, I hope we can get rid of shell in general :)

btw about RPCs and runtime apis, Bryan and I recently wrote: https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/custom_runtime_api_rpc/index.html

cmd.run(partial.client)
}

#[cfg(any(feature = "runtime-benchmarks"))]
Copy link
Contributor

Choose a reason for hiding this comment

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

I have raised this in another PR as well, high level my understanding is that we should be able to already remove all traces of benchmarking from normal nodes, not to mention the omni-node. @ggwpez any comments from you, re. how far we are from this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@ggwpez , can you take a look on the question above please ?

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 since it's pretty verbose and I would like to avoid merge conflicts. I will address this point in a future PR.

Copy link
Contributor

@kianenigma kianenigma left a comment

Choose a reason for hiding this comment

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

Looks significantly better! Some comments left, but all are thoughts for the future.

@skunert
Copy link
Contributor

skunert commented Jul 4, 2024

One use-case I was thinking about during the review is temporary or experimental features. One example is a --experimental-use-slot-based command line flag that will enable a new experimental collator.

Previously I was just adding this flag and based on it choosing the closure to start consensus, here. With the model proposed here stuff like this gets a bit harder, I would need to implement StartConsensus and a new NodeSpec that uses it.

One reasonable addition would be to have some struct like extra_args (name is shitty 😬 ) that gets added to the parameters of the associated types.

Yes, sounds good. The extra_args struct should be the right solution in this case. But I wouldn't add it now since it would just be an unused empty struct. I would add it together with the --experimental-use-slot-based logic. If you merge #4097 first, I can then add it here when I fix the conflicts. Or if this PR gets merged first, please can you add it in #4097 ?

Lets try to merge #4097 first and then integrate here.

@serban300 serban300 mentioned this pull request Jul 8, 2024
@serban300
Copy link
Contributor Author

serban300 commented Jul 8, 2024

Lets try to merge #4097 first and then integrate here.

@skunert Done. I integrated #4097 into this PR. PTAL !

For the experimental_use_slot_based_flag I added a new_aura_node_spec constructor that receives the flag and then it just plugs-in the required StartConsensus into the AuraNode. Please check this commit. It seemed simpler than providing an extra_args param to all the associated traits.

@bkchr
Copy link
Member

bkchr commented Jul 8, 2024

For the experimental_use_slot_based_flag I added a new_aura_node_spec constructor that receives the flag and then it just plugs-in the required StartConsensus into the AuraNode

Please make it a struct from the beginning. In the future that will be much easier to forward there stuff if we have a struct.

Also, please use if for checking booleans :D

Copy link
Contributor

@skunert skunert left a comment

Choose a reason for hiding this comment

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

I agree that the extra args should be a struct.

Once that is addressed, good to merge from my side, nice!

@serban300
Copy link
Contributor Author

Please make it a struct from the beginning. In the future that will be much easier to forward there stuff if we have a struct.

I agree that the extra args should be a struct.

Done

Also, please use if for checking booleans :D

Done

Copy link
Member

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

One last nitpick. Then we are good to go.

cumulus/polkadot-parachain/src/service.rs Outdated Show resolved Hide resolved
cumulus/polkadot-parachain/src/cli.rs Outdated Show resolved Hide resolved
Runtime::Penpal(_) =>
new_aura_node_spec::<AuraRuntimeApi, AuraId>(extra_args.experimental_use_slot_based),
Runtime::Shell | Runtime::Seedling => Box::new(ShellNode),
Runtime::Glutton => Box::new(BasicLookaheadNode),
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Runtime::Glutton => Box::new(BasicLookaheadNode),

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

cumulus/polkadot-parachain/src/command.rs Show resolved Hide resolved
@serban300
Copy link
Contributor Author

I see that the following tests are failing:

  • gitlab-zombienet-cumulus-0007-full_node_warp_sync
  • gitlab-zombienet-substrate-0002-validators-warp-sync
  • gitlab-zombienet-substrate-0003-block-building-warp-sync

But doesn't seem related to this PR. They are also failing in all latest PRs (https://github.com/paritytech/polkadot-sdk/pulls) with the same errors:

2024-07-08T22:49:44.045Z zombie::network-node current value: undefined for metric substrate_beefy_best_block, keep trying...
2024-07-08T23:11:03.075Z zombie::network-node current value: undefined for metric block height, keep trying...

Copy link
Member

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

@bkchr
Copy link
Member

bkchr commented Jul 9, 2024

I see that the following tests are failing:

* gitlab-zombienet-cumulus-0007-full_node_warp_sync

* gitlab-zombienet-substrate-0002-validators-warp-sync

* gitlab-zombienet-substrate-0003-block-building-warp-sync

But doesn't seem related to this PR. They are also failing in all latest PRs (https://github.com/paritytech/polkadot-sdk/pulls) with the same errors:

2024-07-08T22:49:44.045Z zombie::network-node current value: undefined for metric substrate_beefy_best_block, keep trying...
2024-07-08T23:11:03.075Z zombie::network-node current value: undefined for metric block height, keep trying...

The BEEFY errors are not related to your changes here. Generally these tests are quite flaky..

@serban300 serban300 added this pull request to the merge queue Jul 9, 2024
Merged via the queue into paritytech:master with commit 01e0fc2 Jul 9, 2024
157 of 162 checks passed
@serban300 serban300 deleted the polkadot-parachain-refactoring branch July 9, 2024 08:59
TomaszWaszczyk pushed a commit to TomaszWaszczyk/polkadot-sdk that referenced this pull request Jul 13, 2024
)

`polkadot-parachain` simplifications and deduplications

Details in the commit messages. Just copy-pasting the last commit
description since it introduces the biggest changes:

```
    Implement a more structured way to define a node spec
    
    - use traits instead of bounds for `rpc_ext_builder()`,
      `build_import_queue()`, `start_consensus()`
    - add a `NodeSpec` trait for defining the specifications of a node
    - deduplicate the code related to building a node's components /
      starting a node
```

The other changes are much smaller, most of them trivial and are
isolated in separate commits.
ordian added a commit that referenced this pull request Jul 15, 2024
* master: (120 commits)
  network/tx: Ban peers with tx that fail to decode (#5002)
  Try State Hook for Bounties (#4563)
  [statement-distribution] Add metrics for distributed statements in V2 (#4554)
  added sync command (#4818)
  Bridges V2 refactoring backport and `pallet_bridge_messages` simplifications (#4935)
  xcm-executor: Improve logging (#4996)
  Remove usage of `sp-std` on templates (#5001)
  fixed cmd bot commenting not working (#5000)
  Explain usage of `<T: Config>` in FRAME storage + Update parachain pallet template  (#4941)
  Expose metadata-hash feature from polkadot crate (#4886)
  Add `MAX_INSTRUCTIONS_TO_DECODE` to XCMv2 (#4978)
  add notices to the implementer's guide docs that changed for elastic scaling (#4983)
  `polkadot-parachain` simplifications and deduplications (#4916)
  Update Templates README docs (#4980)
  allow clear_origin in safe xcm builder (#4777)
  litep2p/peerstore: Fix bump last updated time (#4971)
  Make `tracing::log` work in the runtime (#4863)
  sp-core: Improve docs generated by `generate_feature_enabled_macro` (#4968)
  [Backport] Version bumps  and  prdocs reordering from 1.14.0 (#4955)
  Assets: can_decrease/increase for destroying asset is not successful (#3286)
  ...
TarekkMA pushed a commit to moonbeam-foundation/polkadot-sdk that referenced this pull request Aug 2, 2024
)

`polkadot-parachain` simplifications and deduplications

Details in the commit messages. Just copy-pasting the last commit
description since it introduces the biggest changes:

```
    Implement a more structured way to define a node spec
    
    - use traits instead of bounds for `rpc_ext_builder()`,
      `build_import_queue()`, `start_consensus()`
    - add a `NodeSpec` trait for defining the specifications of a node
    - deduplicate the code related to building a node's components /
      starting a node
```

The other changes are much smaller, most of them trivial and are
isolated in separate commits.
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
Status: Done
Development

Successfully merging this pull request may close these issues.

4 participants