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

x{stake,slash,gov,distrib} In-place Store Migrations #8504

Merged
merged 60 commits into from Feb 25, 2021
Merged

Conversation

amaury1093
Copy link
Contributor

@amaury1093 amaury1093 commented Feb 3, 2021

Description

Add in-place store key migrations in x{stake,slash,gov,distrib} module's legacy folder:

  • copy the old keys.go (from the 41), put them in legacy/041/keys.go
  • add tests that migration scripts from 041 to 042 work
  • update SPEC for these modules

ref: #8345
depends on: #8485


Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

  • Targeted PR against correct branch (see CONTRIBUTING.md)
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Code follows the module structure standards.
  • Wrote unit and integration tests
  • Updated relevant documentation (docs/) or specification (x/<module>/spec/)
  • Added relevant godoc comments.
  • Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
  • Re-reviewed Files changed in the Github PR explorer
  • Review Codecov Report in the comment section below once CI passes

amaury1093 and others added 6 commits February 5, 2021 16:11
Co-authored-by: Robert Zaremba <robert@zaremba.ch>
Co-authored-by: Robert Zaremba <robert@zaremba.ch>
Co-authored-by: Robert Zaremba <robert@zaremba.ch>
Copy link
Collaborator

@robert-zaremba robert-zaremba left a comment

Choose a reason for hiding this comment

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

Few remarks:

  • Let's avoid extending Keeper responsibility for handling migrations. In a comment I proposed 2 options.
  • We put migrations in legacy package. This pattern forces to copy current code to into a legacy package, before it gets legacy
  • I would prefer to limit the amount of code we copy (there are functions we copied which are not used).

simapp/app_test.go Outdated Show resolved Hide resolved
simapp/app_test.go Outdated Show resolved Hide resolved
x/distribution/keeper/migrations.go Show resolved Hide resolved
// Migrate1 implements MigrationKeeper.Migrate1 method.
func (keeper Keeper) Migrate1(ctx sdk.Context) error {
return v042.MigrateStore(ctx, keeper.storeKey)
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Instead of enlarging the Keeper interface and responsibilities, let's create a Migrator structure:

type Migrator struct {
   keeper Keeper
}

// in RegisterServies
m := Migrator(keeper)
cfg.RegisterMigration(types.ModuleName, 1, m.Migrate1)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Other idea is just to make this functions directly:

cfg.RegisterMigration(types.ModuleName, 1,
    func (ctx) {return v42.MigrateStore(ctx, keeper.storeKey)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

func (ctx) {return v42.MigrateStore(ctx, keeper.storeKey)

This would be ideal, but we can't access private keeper.storeKey there.

OK for the Migrator way.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

binary.BigEndian.PutUint64(periodBz, period)
prefix := GetValidatorSlashEventKeyPrefix(v, height)
return append(prefix, periodBz...)
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we need to copy all this functions? For example, it seams that the function above is not used in migrations.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, for legacy stuff, I'm not trying to optimize. Just copy-pasting the whole file seems easier than going through in details what's needed and what's not.

lmk what you think.

@@ -0,0 +1,70 @@
package v042
Copy link
Collaborator

Choose a reason for hiding this comment

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

why do we create legacy/v042? This version is not even released .

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah okay, we can create that later, I'll use types for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I removed the legacy/*/keys.go in f3ca3e5 . However I kept the v042 package, because the migration script from 0.41->0.42 lives in legacy/*/v042.

Copy link
Collaborator

Choose a reason for hiding this comment

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

So that was my point - why putting the migration code in legacy/*/v042? v0.42 is not legacy. It's "current"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ah I see. Well imo it shoud live in a folder called x/module/{something}/v042. We can rename something from "legacy" to "migrations" in a future PR if you want.

Copy link
Collaborator

Choose a reason for hiding this comment

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

yeah, migrations sounds better

Copy link
Contributor Author

Choose a reason for hiding this comment

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

x/distribution/spec/02_state.md Outdated Show resolved Hide resolved
Copy link
Collaborator

@robert-zaremba robert-zaremba left a comment

Choose a reason for hiding this comment

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

Good. Thanks for updating the package structure.

Copy link
Member

@aaronc aaronc left a comment

Choose a reason for hiding this comment

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

Can you explain your logic for starting ConsensusVersion at 1 @AmauryM? Maybe you addressed this in #8485 already but it seems like it would be simplest if we just used the default value of 0. What scenarios are you trying to deal with using 1? Are you thinking that 0 would represent the absence of a module?

@amaury1093
Copy link
Contributor Author

amaury1093 commented Feb 23, 2021

@aaronc Main reason is to explicit set values for all modules in the MigrationMap to avoid potential mistakes: #8485 (comment)

Edit: "Are you thinking that 0 would represent the absence of a module?" Thinking about it, that could be useful too? To differentiate new modules from existing ConsensusVersion=0 modules during an upgrade.

@aaronc
Copy link
Member

aaronc commented Feb 23, 2021

@aaronc Main reason is to explicit set values for all modules in the MigrationMap to avoid potential mistakes: #8485 (comment)

Edit: "Are you thinking that 0 would represent the absence of a module?" Thinking about it, that could be useful too? To differentiate new modules from existing ConsensusVersion=0 modules during an upgrade.

Okay, so basically if the existing version is 0, that actually means the module was just added in this upgrade and therefore shouldn't have any old state migrated. Is that the idea?

@amaury1093
Copy link
Contributor Author

Okay, so basically if the existing version is 0, that actually means the module was just added in this upgrade and therefore shouldn't have any old state migrated. Is that the idea?

Yes.

func (keeper BaseKeeper) Migrate1(ctx sdk.Context) error {
return v042.MigrateStore(ctx, keeper.storeKey)
// Migrate1 migrates from version 1 to 2.
func (m Migrator) Migrate1(ctx sdk.Context) error {
Copy link
Collaborator

Choose a reason for hiding this comment

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

How about naming this as Migrate1to2?

@@ -0,0 +1,70 @@
package v042
Copy link
Collaborator

Choose a reason for hiding this comment

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

yeah, migrations sounds better

@amaury1093 amaury1093 added the A:automerge Automatically merge PR once all prerequisites pass. label Feb 25, 2021
@mergify mergify bot merged commit ba74a7c into master Feb 25, 2021
@mergify mergify bot deleted the am-8345-modules branch February 25, 2021 10:43
@ethanfrey ethanfrey mentioned this pull request Mar 16, 2021
4 tasks
larry0x pushed a commit to larry0x/cosmos-sdk that referenced this pull request May 22, 2023
* Add 1st version of migrate

* Put migration logic into Configurator

* add test to bank store migration

* add test for configurator

* Error if no migration found

* Remove RunMigrations from Configurator interface

* Update spec

* Rename folders

* copy-paste from keys.go

* Fix nil map

* rename function

* Update simapp/app.go

Co-authored-by: Robert Zaremba <robert@zaremba.ch>

* Update simapp/app_test.go

Co-authored-by: Robert Zaremba <robert@zaremba.ch>

* Adderss reviews

* Fix tests

* Update testutil/context.go

Co-authored-by: Robert Zaremba <robert@zaremba.ch>

* Update docs for ConsensusVersion

* Rename to forVersion

* Fix tests

* Check error early

* Return 1 for intiial version

* Use MigrationKeeper

* Fix test

* Revert adding marshaler to Configurator

* Godoc updates

* Update docs

* Add distrib legacy folder

* Add tests for distrib migration

* Add gov migrations

* Copy paste whole keys file

* Add gov migrations

* Add staking

* Fix staking tests

* Update spec and module.go

* Update to latest changes

* Update migration scripts

* capability to 1

* Fix tests

* Add package godoc

* Remove whitespace

* Remove global

* Use Migrator

* Remove 042 keys files

* Fix build

* Unlambda

* Rename to Migrate1to2

Co-authored-by: Robert Zaremba <robert@zaremba.ch>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:automerge Automatically merge PR once all prerequisites pass. C:Store C:x/distribution distribution module related C:x/gov C:x/slashing C:x/staking
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants