Runtime level storage migration

[h4x3rotab]

In the past, we assume the storage migrations are always handled by the on_runtime_upgrade hooks in the pallet. However this is not the approach adopted by Polkadot. Instead, they write the runtime-level migration to trigger the logic defined in each pallets.

I consider this approach better. A lot of pallets come from FRAME. They will be upgraded when we update the substrate dependencies. In this case, we always want to be aware of any storage migration rather than to have it executed silently.

By manually trigger the storage migration, we can be sure what migrations will be executed on each runtime release. On the other hand, it becomes a problem that the downstream may miss some migrations. For instance, Khala v1090 was upgraded from substrate v0.9.10 to v0.9.13, which requires the migration of Council, TechnicalCommittee, Tips, and Bounties. As a result, the pallets were broken after the upgrade.

As a short term solution, we can follow a strict process before each runtime release to check the required storage migrations, and only release after the full test. The process is still error prone. So in long term, we should have some post-upgrade check to ensure all the pallets is at the correct storage version. Ideally every pallet should do the self-check. So maybe it's a good idea to implement at Substrate.

This issue tracks:

• The fix of the Khala v1090 upgrade accident
  • Add pallet migrations between v0.9.10 and v0.9.13 khala-parachain#54
  • Temporary motion #0 to enact the runtime upgrade
• Solution to prevent from missing some future storage migrations

[jasl]

We should follow Polkadot's way that after Runtime upgrade, we should remove migrated migrations, e.g. paritytech/polkadot#4107

[h4x3rotab]

Feel good to close this issue. Parity is doing a good job recently when coordinating the upstream upgrade, and we regularly check the runtime migration from Substrate repo.