-
Notifications
You must be signed in to change notification settings - Fork 740
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
parachain-template: genesis config presets added #4739
parachain-template: genesis config presets added #4739
Conversation
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.
Would we make different choices if we know we want this code in all 3 runtimes? maybe reusing parts of it?
We need indeed want this code to also be in the solochain
and minimal
runtime as well :)
pub const PRESET_LOCAL_TESTNET: &str = "local_testnet"; | ||
|
||
/// Preset configuration name for a development environment. | ||
pub const PRESET_DEVELOPMENT: &str = "development"; |
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.
One annoying little detail about this is that if you don't put chian_type: Dev
in the chain-spec, PJS apps won't show the accounts to you. There is a CLI flag for that two, but seem annoying to repeat development
many times.
./chain-spec-builder --chain-type development --preset development etc etc
We either create a ticket in PJS apps to change this (prob better), or we think about how we can improve it on our side. Maybe a chain-spec-builder --dev
that does both? combined with running the chain in --dev
it sounds like a good dev ex to me.
# compile wasm
# ./chain-spec-builder --runtime wasm --dev > spec.json
# ./omni-node --chain spec.json --dev
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.
chain-spec-builder --dev
This would assume that presets' naming is somehow standardized. Every runtime shall provide something in order to make flags in some other tool work correctly. This is probably OK, question is we want to go in that direction.
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.
To me it sounds reasonable that these are separate flags. You could have multiple runtime presets for development, all of them with chainType "Dev".
I was thinking how one could do the pjs route. I think currently pjs calls the system_chainType
RPC which gets its data directly from the chain spec. If we don't want to use the chain-spec property for this, we would need another easy way to tell that we are a dev chain.
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.
We can keep separate flags, --dev
can be convenient shortcut.
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.
yeah, let's keep all things configurable in the super-user mode, but one --dev
that makes some assumptions is a good nice to have.
To which part are you referring to?
This could be moved to common crate, but at the moment template runtimes are not having common base (e.g. every runtime type is different). This could be done in some follow-up step. |
We are eager to have this merged to improve the parachain developer experience. This will allow customizing chainspecs for launching networks in a generic and easy way without requiring the node binary just the chain-spec-builder + runtime file. |
@skunert @kianenigma what is your opinion - could we merge it and improve it further in follow-up PRs? |
The CI pipeline was cancelled due to failure one of the required jobs. |
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.
From my side looks good, I think we can merge this.
Oh, I also did something similar to this as a part of #5117, and in fact wanted to extract it into a separate PR! But great to see it already exist, review will follow now. |
), | ||
], | ||
vec![ | ||
get_account_id_from_seed::<sr25519::Public>("Alice"), |
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.
Ah i have seen this crap in a lot of places being copy pasted 🙈
Similarly, I have what I think is a better way in #5117:
sp_keyring::Keyring::iter()
- re-export it from
frame
as well for better discover-ability.
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 like it. Not sure however, if Keyring
actually shall go to frame?
Let's do this in the followup - there will following work for solochain and minimal.
Some common parts need to be extracted, probably the accounts in presets can be unified somehow.
(also see #4739 (comment) which needs to be addressed).
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.
@iulianbarbu this is a pretty easy one for you to pick up :)
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.
@kianenigma I am a bit late to the party. Based on the context on this thread I get that we want to do something like sp_keyring::Keyring::Alice.to_account_id()
for the specific line where the thread started, and in general, for creating vec's we want to create them based on sp_keyring::Keyring::iter()
.
I do not get the context around re-export it from 'frame' as well for better discover-ability
. Maybe we can sync offline (to not pollute anymore this merged PR) and maybe open an issue (if there isn't one) which clarifies next steps.
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.
It is about exporting that from the frame main library:
polkadot-sdk/substrate/frame/src/lib.rs
Line 171 in e002e31
pub use sp_keyring::AccountKeyring; |
Which was initially proposed by @kianenigma in this (not merged) #5117 PR.
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.
re-export it from 'frame' as well for better discover-ability basically means that you don't need extra use
/ crate dep (sp_keyring
) when defining presets, it is just imported by frame::runtime
.
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 see now. Thanks!
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.
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 trying re-export sp-keyring
from frame
in #5899, @kianenigma are you doing the similar work?
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.
No, I am not doing a similar thing.
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.
Looks good, just have a few suggestions
I think a cool and bold next step in the omni direction would be to actually feature gate the entire node
in our templates, and if you run it, show you a message that would show you instead how you should run your chain with chopsticks + polkadot-parachain + chain-spec-builder + frame-omni-bencher.
I've been meaning to write some kind of a guide about how to mix the above 4 into a project and use them, but haven't managed to get it together. Perhaps it is finally time.
# Description Closes [#5790](#5790). Useful for starting nodes based on minimal/solochain when doing development or for testing omni node with less happy code paths. It is reusing the presets defined for the nodes chain specs. ## Integration Specifically useful for development/testing if generating chain-specs for `minimal` or `solochain` runtimes from `templates` directories. ## Review Notes Added `genesis_config_presets` modules for both minimal/solochain. I reused the presets defined in each node `chain_spec` module correspondingly. ### PRDOC Not sure who uses templates, maybe node devs and runtime devs at start of their learning journey, but happy to get some guidance on how to write the prdoc if needed. ### Thinking out loud I saw concerns around sharing functionality for such genesis config presets between the template chains. I think there might be a case for doing that, on the lines of this comment: #4739 (comment). I would add that `parachains-common::genesis_config_heleper` contains a few methods from those mentioned, but I am unsure if using it as a dependency for templates is correct. Feels like the comment suggests there should be a `commons` crate concerning just `templates`, which I agree with to some degree, if we assume `cumulus` needs might be driven in certain directions that are not relevant to `templates` and vice versa. However I am not so certain about this, so would welcome some thoughts, since I am seeing `parachains-common` being used already in a few runtime implementations: https://crates.io/crates/parachains-common/reverse_dependencies?page=3, so might be a good candidate already for the `common` logic. --------- Signed-off-by: Iulian Barbu <[email protected]>
Gensis config presets moved from
parachain-template-node
binary intoparachain-template-runtime
runtime.cc: @PierreBesson