-
Notifications
You must be signed in to change notification settings - Fork 721
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
add dev-omni-node #5117
add dev-omni-node #5117
Conversation
Good idea.
We should just change the basic |
Not sure if this is a question, but this error is probably originated here: polkadot-sdk/substrate/client/service/src/builder.rs Lines 151 to 156 in 604f56f
|
We would need some way to say Or we can simply agree that |
Precisely, and I was talking to this with @ggwpez as well. He has used I also see some issues with using
How is a pallet meant to express this though? A pallet can only declare Beyond this, I can work on amending the
|
My feeling is that initial config (preset) is property of runtime, not pallet. The pallet never knows in which configuration/context it will be embedded into runtime. Editied - second thought: maybe trait like this would make sense for pallet for the sake of devex improvements? Sth like: trait PresetProvider { fn preset(name: PresetId) -> json::Value } or more opinionated trait DevPresetProvider { fn dev_preset() -> json::Value } This could be combined into full |
What you say makes sense. But, at the same time, it kinda sucks as well that when testing |
I feel it. (I also re-edited my previous comment). |
I've experimented with this in 3e55a98 There's still the same error as above for genesis build code path, but it is solve-able. |
The runtime should expose some sensible genesis when the |
Just a kind reminder about the assumptions we made to build presets (discussion about api):
I am just wondering: if One solution is to get rid of patches, and provide only full genesis configs - but I personally think patches are nice for development (e.g. in zombienet). My opinion is that we should have standardized |
I agree to "We should not start trying to push presets to pallets" part, as most often sensible genesis is dependent on multiple pallets to begin with. But I am hesitant about "The runtime should expose some sensible genesis when the For example, in testing, you want your I am still arguing for:
|
For a correct genesis you will need the correct authorities. You will not have the authorities until you start preparing your launch. I see where you are coming from. However, "a correct genesis" is a little bit more complex and not just exists. I mean we can go for passing "dev" and then live with "None" giving no correct value until the runtime is ready for launch. |
This notion of authority is also a bit dated, isn't it? It all goes back to launching a local chain with aura/babe/grandpa etc. which this node does not care about at all. I am not decided on this yet tbh. Let me explore a bit more and come back here with more insights. |
Please do not try again to come up with a new node. Not sure why this node doesn't care. I mean I see where you are coming from. But then you will need more code written to build blocks without any kind of consensus logic. |
The CI pipeline was cancelled due to failure one of the required jobs. |
Closing this as it we decided to give it another shot to integrate it properly into a new subcommand of |
Initially, we tried to introduce this as a part of #5027, but it turned out to be a bit needlessly cumbersome to add the CLI parameterization (see #5027 (review)). For now it is simpler to add a
dev-omni-node
binary separately. This will allow me to revive #3946 as well.What I would like to achieve here, but I am having a hard time with, is to allow users to optionally circumvent generating a chain-spec, by providing just a
.wasm
file.Initially, I tried this with a new
--runtime
that is mutually exclusive with--chain
. This could work, but the downside is that it is a new flag, and that I couldn't yet make clap understand the relationship between --chain and--runtime
, because--chain
is flattened.Preferably, I would like to achieve what the code does here: If
--chain
is given.wasm
file, generate a default chain spec for it. If not, parse it as a normal chain spec. But, somewhere else in the code other thanload_spec
, we are trying to read the spec, and a.wasm
file is not parse-able as JSON. THe error should help one figure out where this is happening:It is also unfortunate that
--dev
cannot really be supported in this case, and--temp
is not the default. I should explore options to achieve this.