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

Rework migration and on runtime upgrade logic execution #1315

Open
wants to merge 15 commits into
base: master
Choose a base branch
from

Conversation

dmitrylavrenov
Copy link
Contributor

@dmitrylavrenov dmitrylavrenov commented Nov 1, 2024

The main goal of this PR is to avoid running runtime upgrade execution for each pallet on each runtime upgrade. The idea is taken from substrate and polkadot-sdk approach to use an ability passing actual migration at the runtime itself.

There are introduced separate objects responsible for runtime upgrade logic that implement OnRuntimeUpgrade to be passed at humanode-runtime to Executive like:

/// Executive: handles dispatch to the various modules.
pub type Executive = frame_executive::Executive<
    Runtime,
    Block,
     frame_system::ChainContext<Runtime>,
     Runtime,
     AllPalletsWithSystem,
     (
         init_storage_version::InitStorageVersion<DummyPrecompilesCode, Runtime>,
         init_storage_version::InitStorageVersion<BalancedCurrencySwapBridgesInitializer, Runtime>,
     ),
 >;

@dmitrylavrenov dmitrylavrenov force-pushed the rework-migration-logic branch 2 times, most recently from 3323773 to 2cb6dc3 Compare November 1, 2024 12:42
@dmitrylavrenov dmitrylavrenov changed the title Rework migration logic Rework migration and on runtime upgrade logic execution Nov 1, 2024
@dmitrylavrenov dmitrylavrenov force-pushed the rework-migration-logic branch 9 times, most recently from 10f7009 to ab80d9c Compare November 7, 2024 10:25
@dmitrylavrenov dmitrylavrenov changed the base branch from master to imporve-runtime-logs November 7, 2024 10:25
@dmitrylavrenov dmitrylavrenov force-pushed the rework-migration-logic branch 2 times, most recently from ab80d9c to 48a39c7 Compare November 7, 2024 15:09
@dmitrylavrenov dmitrylavrenov changed the base branch from imporve-runtime-logs to master November 7, 2024 15:09
@dmitrylavrenov dmitrylavrenov force-pushed the rework-migration-logic branch 6 times, most recently from 0af952a to b78da82 Compare November 8, 2024 12:41
@dmitrylavrenov dmitrylavrenov marked this pull request as ready for review November 8, 2024 12:44
Copy link
Contributor

@MOZGIII MOZGIII left a comment

Choose a reason for hiding this comment

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

Please explain the logic behind this change - in particular why alter all the pallets

@dmitrylavrenov
Copy link
Contributor Author

Please explain the logic behind this change - in particular why alter all the pallets

Added to the description

@dmitrylavrenov dmitrylavrenov force-pushed the rework-migration-logic branch 10 times, most recently from 05b4304 to c5d8330 Compare November 20, 2024 13:54
@dmitrylavrenov dmitrylavrenov marked this pull request as ready for review November 21, 2024 12:53
@MOZGIII
Copy link
Contributor

MOZGIII commented Nov 21, 2024

We'd have to put this on hold for now, a I need to do more research on this and dig deeper to really conclude something propely; note there are no useless migrations, and, in principle, migrations are to be kept forever; unless there is a special certain cutoff date for them.

@dmitrylavrenov
Copy link
Contributor Author

We'd have to put this on hold for now, a I need to do more research on this and dig deeper to really conclude something propely; note there are no useless migrations, and, in principle, migrations are to be kept forever; unless there is a special certain cutoff date for them.

Got it. The PR is not about avoiding having useless migrations, but to make the migrations itself more flexible. We can always have it at runtime level to keep it forever but control all migrations in one place.

Btw, looking forward to doing more research on your side and discussing later. I just was inspired by the general logic of custom upgrades usage after researching substrate updates related to polkadot-v0.9.43.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants