parachain-template: genesis config presets added by michalkucharczyk · Pull Request #4739 · paritytech/polkadot-sdk

michalkucharczyk · 2024-06-08T09:36:01Z

Gensis config presets moved from parachain-template-node binary into parachain-template-runtime runtime.

kianenigma

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 :)

kianenigma · 2024-06-10T00:20:37Z

templates/parachain/runtime/src/genesis_config_presets.rs

+pub const PRESET_LOCAL_TESTNET: &str = "local_testnet";
+
+/// Preset configuration name for a development environment.
+pub const PRESET_DEVELOPMENT: &str = "development";


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

cc @gupnik @shawntabrizi

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.

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.

We can keep separate flags, --dev can be convenient shortcut.

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.

michalkucharczyk · 2024-06-10T06:07:58Z

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 :)

To which part are you referring to?
I think this is the part that will be duplicated:

const SAFE_XCM_VERSION: u32 = xcm::prelude::XCM_VERSION;
pub fn get_from_seed<TPublic: Public>(seed: &str) -> <TPublic::Pair as Pair>::Public {
pub fn get_collator_keys_from_seed(seed: &str) -> AuraId {
pub fn get_account_id_from_seed<TPublic: Public>(seed: &str) -> AccountId
pub fn template_session_keys(keys: AuraId) -> SessionKeys {

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). solochain does not need collator.
Maybe those functions are not really needed and all the key generation could be simplified. I did not look at this yet.

This could be done in some follow-up step.

PierreBesson · 2024-07-24T09:23:05Z

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.

michalkucharczyk · 2024-07-24T10:09:34Z

@skunert @kianenigma what is your opinion - could we merge it and improve it further in follow-up PRs?

paritytech-cicd-pr · 2024-07-24T10:12:15Z

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-clippy
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6796229

skunert

From my side looks good, I think we can merge this.

kianenigma · 2024-08-02T16:13:38Z

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.

templates/parachain/runtime/src/genesis_config_presets.rs

kianenigma · 2024-08-02T16:18:24Z

templates/parachain/runtime/src/genesis_config_presets.rs

+			),
+		],
+		vec![
+			get_account_id_from_seed::<sr25519::Public>("Alice"),


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.

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

@iulianbarbu this is a pretty easy one for you to pick up :)

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

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.

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.

I see now. Thanks!

Please also see https://github.com/paritytech/polkadot-sdk/pull/5327/files#r1758961989

I am trying re-export sp-keyring from frame in #5899, @kianenigma are you doing the similar work?

No, I am not doing a similar thing.

kianenigma

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.

…plates-parachain

# 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 <iulian.barbu@parity.io>

parachain-template: genesis config presets added

d5f9643

michalkucharczyk requested review from a team and kianenigma June 8, 2024 09:36

michalkucharczyk added R0-no-crate-publish-required The change does not require any crates to be re-published. T11-documentation This PR/Issue is related to documentation. labels Jun 8, 2024

michalkucharczyk added 2 commits June 8, 2024 14:52

clippy

089f7a5

fmt

1f7eea9

kianenigma reviewed Jun 10, 2024

View reviewed changes

Merge branch 'master' into mku-presets-for-templates-parachain

bd7ba7a

fixes

9dfe164

skunert approved these changes Jul 24, 2024

View reviewed changes

kianenigma reviewed Aug 2, 2024

View reviewed changes

templates/parachain/runtime/src/genesis_config_presets.rs Outdated Show resolved Hide resolved

kianenigma reviewed Aug 2, 2024

View reviewed changes

kianenigma approved these changes Aug 2, 2024

View reviewed changes

kianenigma mentioned this pull request Aug 5, 2024

Make polkadot-sdk templates OMNI and GREAT again -- part 2 #5242

Closed

18 tasks

kianenigma added the T17-Templates This PR/Issue is related to templates label Aug 5, 2024

michalkucharczyk mentioned this pull request Aug 30, 2024

Moved presets to the testnet runtimes #5327

Merged

8 tasks

michalkucharczyk added 3 commits August 30, 2024 18:03

review comments applied

399ca86

Merge remote-tracking branch 'origin/master' into mku-presets-for-tem…

2e0c2e9

…plates-parachain

prdoc added

31801e8

michalkucharczyk enabled auto-merge August 30, 2024 16:28

michalkucharczyk disabled auto-merge August 30, 2024 16:28

michalkucharczyk added 2 commits August 30, 2024 18:41

doc fix

a7a4ef9

Merge branch 'master' into mku-presets-for-templates-parachain

dc945c3

michalkucharczyk added this pull request to the merge queue Aug 30, 2024

Merged via the queue into master with commit 562870d Aug 30, 2024

michalkucharczyk deleted the mku-presets-for-templates-parachain branch August 30, 2024 20:18

ggwpez mentioned this pull request Sep 9, 2024

Parent issue for stable2409 LTS release #5583

Closed

iulianbarbu mentioned this pull request Sep 16, 2024

Refactor get_account_id_from_seed / get_from_seed to one common place #5705

Closed

iulianbarbu mentioned this pull request Sep 30, 2024

templates: add genesis config presets for minimal/solochain #5868

Merged

github-actions bot mentioned this pull request Oct 8, 2024

Update polkadot-sdk from stable2407 to stable2409 moonbeam-foundation/moonbeam#2994

Closed

TDemeco mentioned this pull request Oct 14, 2024

feat: ⏫ upgrade to Polkadot SDK stable2409 Moonsong-Labs/storage-hub#228

Merged

github-actions bot mentioned this pull request Dec 5, 2024

Update polkadot-sdk from stable2407 to stable2409-2 moonbeam-foundation/moonbeam#3075

Closed

pgherveou added this to [preview] release tracker Mar 20, 2026

github-project-automation bot moved this to Done in [preview] release tracker Mar 20, 2026

pgherveou removed this from [preview] release tracker Mar 20, 2026

pgherveou added this to [preview] release tracker Mar 23, 2026

github-project-automation bot moved this to Done in [preview] release tracker Mar 23, 2026

Conversation

michalkucharczyk commented Jun 8, 2024

Uh oh!

kianenigma left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

michalkucharczyk Jun 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

michalkucharczyk commented Jun 10, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

PierreBesson commented Jul 24, 2024

Uh oh!

michalkucharczyk commented Jul 24, 2024

Uh oh!

paritytech-cicd-pr commented Jul 24, 2024

Uh oh!

skunert left a comment

Choose a reason for hiding this comment

Uh oh!

kianenigma commented Aug 2, 2024

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

michalkucharczyk Sep 13, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

michalkucharczyk Sep 13, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kianenigma left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

michalkucharczyk Jun 10, 2024 •

edited

Loading

michalkucharczyk commented Jun 10, 2024 •

edited

Loading

michalkucharczyk Sep 13, 2024 •

edited

Loading

michalkucharczyk Sep 13, 2024 •

edited

Loading