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

Implement pre-migration framework #5434

Merged
merged 21 commits into from
Jan 28, 2021
Merged

Implement pre-migration framework #5434

merged 21 commits into from
Jan 28, 2021

Conversation

Stebalien
Copy link
Member

@Stebalien Stebalien commented Jan 26, 2021

This PR adds:

  1. A PreMigrations slice to every Upgrade. This can be filled with functions that should be executed
    some number of epochs before the upgrade happens.
  2. A MigrationCache that's passed to both the final Migration function, and any PreMigration functions.
  3. An optional Start/Stop method on the StateManager that starts/stops the pre-migration scheduler.

Finally, this PR wires up pre-migrations for the actors V3 upgrade.

fixes #5415

TODO:

chain/stmgr/forks.go Outdated Show resolved Hide resolved
migration := &migration{
upgrade: upgrade.Migration,
preMigrations: upgrade.PreMigrations,
cache: nv10.NewMemMigrationCache(),
Copy link
Contributor

Choose a reason for hiding this comment

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

a bit messy but I guess it is fine

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, we should probably move it elsewhere, but this works for now. Really, it was that or copy it.

Comment on lines 174 to 179
When: 120,
NotAfter: 60,
}, {
PreMigration: PreUpgradeActorsV3,
When: 30,
NotAfter: 20,
Copy link
Contributor

Choose a reason for hiding this comment

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

Probably should get those epochs from build/

Copy link
Member Author

Choose a reason for hiding this comment

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

Maybe? I mean, these are just saying "do the pre-migration N epochs before the upgrade height". I'm not sure if being able to configure these in the build is all that useful.

Comment on lines 888 to 889
// TODO: tune this.
config := nv10.Config{MaxWorkers: 1}
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we have good/any idea on what this should be?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm setting the pre-migration to half the CPUs, and the migration to all the CPUs. I'll also try at 2x CPUs just to see if it matters.

Copy link
Member Author

Choose a reason for hiding this comment

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

Can you take a look at the current values?

chain/stmgr/forks_test.go Show resolved Hide resolved
chain/stmgr/stmgr.go Show resolved Hide resolved
for _, head := range change {
for len(schedule) > 0 {
op := &schedule[0]
if head.Val.Height() < op.after {
Copy link
Contributor

Choose a reason for hiding this comment

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

We could add some confidence here to make reverts less likely to have impact here (if they even matter)

Copy link
Member Author

Choose a reason for hiding this comment

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

Reverts don't matter.


// Finally, when the head changes, see if there's anything we need to do.
for change := range sm.cs.SubHeadChanges(ctx) {
for _, head := range change {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we also drop the migration caches here after say upgradeEpoch+finality to not keep a bunch of stuff in memory?

Copy link
Member Author

Choose a reason for hiding this comment

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

Hm. Yes, we should. I'll nil out the "ops" as we pass them.

Copy link
Member Author

Choose a reason for hiding this comment

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

Well, actually, it's not quite that simple. I'll see if there's a better way to do this.

chain/stmgr/stmgr.go Outdated Show resolved Hide resolved
chain/stmgr/stmgr.go Outdated Show resolved Hide resolved
// When specifies that this pre-migration should be started at most When epochs before the upgrade.
When abi.ChainEpoch

// NotAfter specifies that this pre-migration should not be started NotAfter epochs before
Copy link
Contributor

Choose a reason for hiding this comment

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

It's a bit more than that, right -- it also means that an in-process migration will be cancelled at this epoch?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, I'm going to to fix that. Really, we need three points in time:

  1. Start after.
  2. Don't start after.
  3. Stop at.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, that sounds better

Copy link
Member Author

Choose a reason for hiding this comment

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

Could you take a look now?

Stebalien and others added 3 commits January 27, 2021 15:41
Co-authored-by: Aayush Rajasekaran <arajasek94@gmail.com>
There are now three times:

1. StartWithin: start within X epochs of the upgrade.
2. DontStartWithin: don't start within X epochs of the upgrade.
3. StopWithin: stop within X epochs of the upgrade.
Copy link
Contributor

@arajasek arajasek left a comment

Choose a reason for hiding this comment

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

LGTM

@arajasek arajasek merged commit 887d40b into master Jan 28, 2021
@arajasek arajasek deleted the feat/pre-migrate branch January 28, 2021 00:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Integrate network upgrade pre-migration
4 participants