-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Move type Migrations
to Config
#14309
Move type Migrations
to Config
#14309
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.
Looks good, left a few comments
you will have to fix cumulus too |
Co-authored-by: PG Herveou <[email protected]>
while we are making this change we might also want to be more strict in - in_storage >= first_supported && target == high
+ in_storage == first_supported && target == high (+ fixing the test that touch this) |
@@ -1240,6 +1241,7 @@ impl pallet_contracts::Config for Runtime { | |||
type MaxStorageKeyLen = ConstU32<128>; | |||
type UnsafeUnstableInterface = ConstBool<false>; | |||
type MaxDebugBufferLen = ConstU32<{ 2 * 1024 * 1024 }>; | |||
type Migrations = (NoopMigration<1>, NoopMigration<2>); |
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.
maybe we can add a quick comments to specify that these noop migrations are used for benchmarking the migration framework.
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 think the things used for tests & benches should not appear here. It's better to keep them where they were, behind a feature flag. That's being said the docs giving an example how to configure the Migrations seq in runtime Config, would be great to have.
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.
A ()
should suffice.
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.
these NoopMigrations are used by benchmarks, so we should keep them here
substrate/frame/contracts/src/benchmarking/mod.rs
Lines 281 to 290 in 28f56b6
#[pov_mode = Measured] | |
migrate { | |
StorageVersion::new(0).put::<Pallet<T>>(); | |
<Migration::<T> as frame_support::traits::OnRuntimeUpgrade>::on_runtime_upgrade(); | |
let origin: RawOrigin<<T as frame_system::Config>::AccountId> = RawOrigin::Signed(whitelisted_caller()); | |
}: { | |
<Contracts<T>>::migrate(origin.into(), Weight::MAX).unwrap() | |
} verify { | |
assert_eq!(StorageVersion::get::<Pallet<T>>(), 1); | |
} |
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.
Then how does this look like in an actual runtime?
Could be as ugly as this...
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 think the things used for tests & benches should not appear here. It's better to keep them where they were, behind a feature flag. That's being said the docs giving an example how to configure the Migrations seq in runtime Config, would be great to have.
@agryaznov I think that's because that is part of the config, we can't avoid having it here. Compile flags worked before because the type was internal to the pallet.
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.
Then how does this look like in an actual runtime? Could be as ugly as this...
We could do something as ugly as that or as ugly as this (which was the initial approach)
/// Performs all necessary migrations based on `StorageVersion`.
#[cfg(not(feature = "runtime-benchmarks"))]
pub struct Migration<T: Config, M: MigrateSequence = T::Migrations>(PhantomData<(T, M)>);
/// Custom migration for running runtime-benchmarks and tests.
#[cfg(feature = "runtime-benchmarks")]
pub struct Migration<T: Config, M: MigrateSequence = (NoopMigration<1>, NoopMigration<2>)>(
PhantomData<(T, M)>,
);
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 how it is setup in @ggwpez 's link at least it makes it clear that these noopMigration are intended for benchmarks
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 have applied PG's suggested fix #14309 (comment)
@juangirini I don't get the need for this pr. Migrations can already be specified in the runtime substrate/bin/node/runtime/src/lib.rs Lines 1981 to 1985 in b1bb12d
|
@bkchr The idea here is to remove the hardcoded substrate/frame/contracts/src/migration.rs Lines 61 to 63 in b1bb12d
so they can be fine tuned in the runtime. Why do we need this? Then we could have something like impl pallet_contracts::Config for Runtime {
// ...
type Migrations = (v9::Migration<Runtime>, v10::Migration<Runtime, Currency>, v11::Migration<Runtime>); This solution indeed creates the developers the need to maintain the Alternatively, we could let live |
Everything you said is already possible with the way we are doing runtime migrations in the lib.rs |
@bkchr, unlike other pallets, we are using a new multi-block migration framework. The PR #14045 has more details on how it works, but essentially We need this new configuration trait to customize the migration steps in the runtime and use it in the pallet in these 2 places. The frame team is working on a similar solution that might not require such informations in the Config but until then, I believe that is the best way for us to configure our multi-block migrations. Here are the relevant bits of codes discussed: substrate/frame/contracts/src/lib.rs Lines 329 to 332 in e88854a
substrate/frame/contracts/src/lib.rs Lines 745 to 752 in e88854a
substrate/frame/contracts/src/migration.rs Lines 317 to 345 in e88854a
|
@pg thanks for the comment, I was not explicit about the fact that this pallet is using a custom MBM. |
@@ -1240,6 +1241,7 @@ impl pallet_contracts::Config for Runtime { | |||
type MaxStorageKeyLen = ConstU32<128>; | |||
type UnsafeUnstableInterface = ConstBool<false>; | |||
type MaxDebugBufferLen = ConstU32<{ 2 * 1024 * 1024 }>; | |||
type Migrations = (NoopMigration<1>, NoopMigration<2>); |
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 think the things used for tests & benches should not appear here. It's better to keep them where they were, behind a feature flag. That's being said the docs giving an example how to configure the Migrations seq in runtime Config, would be great to have.
Co-authored-by: PG Herveou <[email protected]>
@agryaznov as commented here #14309 (comment) this has been resolved. Even though the feature gated |
bot merge |
Error: Github API says paritytech/cumulus#2701 is not mergeable |
bot merge |
* move migrate sequence to config * remove commented out code * Update frame/contracts/src/lib.rs Co-authored-by: PG Herveou <[email protected]> * remove Migrations generic * make runtime use noop migrations * restrict is_upgrade_supported * undo is_upgrade_supported change * Update bin/node/runtime/src/lib.rs Co-authored-by: PG Herveou <[email protected]> * add rust doc example for `Migrations` * feature gate NoopMigration * fix example code * improve example --------- Co-authored-by: PG Herveou <[email protected]>
* move migrate sequence to config * remove commented out code * Update frame/contracts/src/lib.rs Co-authored-by: PG Herveou <[email protected]> * remove Migrations generic * make runtime use noop migrations * restrict is_upgrade_supported * undo is_upgrade_supported change * Update bin/node/runtime/src/lib.rs Co-authored-by: PG Herveou <[email protected]> * add rust doc example for `Migrations` * feature gate NoopMigration * fix example code * improve example --------- Co-authored-by: PG Herveou <[email protected]>
This PR removes the hardcoded migration sequence from
migrations.rs
and places it withinConfig
so it can be configured in the runtime.How to update the code
Developers need to update their runtime configuration with their pending migrations (or
()
if none). For example:This is a breaking change as it adds a new type to the
Config
, there's another breaking PR #14020 that changes it, so it would be a good idea to have them in the same release.cumulus companion: paritytech/cumulus#2701