Refactor Container chain spawner logic in separate crate #637
Conversation
nanocryk
added
a0-pleasereview
Coverage Report@@ Coverage Diff @@
## master jeremy-refactor-spawner-logic-in-separate-crate +/- ##
===================================================================================
- Coverage 66.88% 66.69% -0.19%
+ Files 255 260 +5
+ Lines 44587 44710 +123
===================================================================================
Hits 29819 29819
+ Misses 14768 14891 +123
|
| let para_id = cli.run.parachain_id.unwrap_or(2000); | ||
|
|
||
| let (_cc_task_manager, _cc_client, _cc_backend) = | ||
| tc_service_container_chain::service::start_node_impl_container( |
There was a problem hiding this comment.
Question about this, we probably need to start this with very different arguments for frontier-like nodes anhd non-frontier-like nodes (specially related to the rpc-nodes). Are we going to be able to do so?
There was a problem hiding this comment.
Or maybe we can wire the ethereum ones to their own rpc-setup, but we for sure need to make sure not to spawn a non-ethereum registered chain in that case.
So start_node_impl_container is likely usable for substrate chains + collators but not for ethereum-nodes
| relay_chain_interface, | ||
| client, | ||
| keystore, | ||
| ParaId::from(2001), |
There was a problem hiding this comment.
Maybe we can ask the orchestrator chain about its own para-id somehow. Is there a runtime-api that we can query for this instead of hardcoding?
Move logic related to starting embeded container chain node to a dedicated crate.
Adds a POC spawning of container chain node inside rpc provider command to ensure it can be called properly with available information.