-
Notifications
You must be signed in to change notification settings - Fork 96
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
Add migration to fix coretime state #458
Add migration to fix coretime state #458
Conversation
This reverts commit 0367a60.
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.
Left a few comments. In general this patch is relatively hard to reason about. Lot's of magic numbers and implicit state tracking - e.g. with core numbers.
assignment: CoreAssignment::Task(para_id), | ||
}])); | ||
|
||
Workplan::<Runtime>::insert((287565, core_id), workplan_entry); |
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.
Confirmed: This is indeed the region_begin.
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.
TODO: Check on what occasions this is sent to the relay chain.
} | ||
|
||
// Incorrect potential renewals in state | ||
const INCORRECT_RENEWAL_IDS: [(u16, u32); 6] = |
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.
Confirmed: all leases added below (compared to coretime chain state) are to be found here.
(2000, 313920), | ||
(3338, 329040), | ||
(2004, 329040), | ||
(3344, 344160), |
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.
Checked (some samples): Values here are indeed offset amount of blocks larger than values in state.
|
||
// Incorrect potential renewals in state | ||
const INCORRECT_RENEWAL_IDS: [(u16, u32); 6] = | ||
[(6, 292605), (5, 292605), (13, 292605), (15, 292605), (47, 292605), (44, 292605)]; |
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.
Checked with chain state: Matching. (This is the entire list of currently registered potential renewals, as expected.)
} | ||
|
||
// Remove the existing 6 PotentialRenewals. | ||
for &(core, when) in INCORRECT_RENEWAL_IDS.iter() { |
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.
// Sort the parachains who can renew. They are currently missing from the broker state | ||
// entirely. | ||
// TODO double check the core ids, these should be on top of the last available in the sale. | ||
for (&(para_id, _), core_id) in POTENTIAL_RENEWALS.iter().zip(56u16..61u16) { |
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've pushed the changes I've suggested in order to ease the code review. Motivation for each change was added as a comment initially.
|
Renewals likely still off.
- PotentialRenewals size - pool core - actual reservations
More correct variant with less assumptions
const POTENTIAL_RENEWALS: [(u32, u32); 5] = | ||
[(2048, 283680), (3375, 283680), (3358, 283680), (2053, 283680), (2056, 283680)]; | ||
|
||
const LEASES: [(u32, u32); 46] = [ |
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.
List fully verified. Complete and correct.
Reworked + fixed tests. The only thing that is really still missing now is weights. Can we just benchmark the function? |
Complete Workplan after migration: 0, CoreAssignment::Task(1001), 287565 Output of: ./target/release/try-runtime create-snapshot --uri wss://coretime-polkadot.dotters.network ./snapshot-coretime-current
RUST_BACKTRACE=1 RUST_LOG=runtime::bootstrapping::fix-migration=debug ./target/release/try-runtime --runtime ../fellowship-runtimes/target/debug/wbuild/coretime-polkadot-runtime/coretime_polkadot_runtime.wasm on-runtime-upgrade snap -p ./snapshot-coretime-current |
To determine the correct lease endings and the paras that have been dropped, I used the following adjusted migration from the relay chain: and ran it at the migrating block via try-runtime: ./target/release/try-runtime create-snapshot --uri wss://rpc-polkadot.luckyfriday.io -a 0x07886d8260a5f0436eda29bf847af211eb53c975754002675ab0e78022441c62 ./snapshot-update
RUST_LOG=coretime-migration=trace ./target/release/try-runtime --runtime ../fellowship-runtimes/target/debug/wbuild/polkadot-runtime/polkadot_runtime.wasm on-runtime-upgrade --disable-spec-version-check snap -p ./snapshot-update The upgrading block hash I determined via subscan: |
/merge |
Enabled Available commands
For more information see the documentation |
afc36ca
into
polkadot-fellows:main
The
LeaseOffset
was not taken into consideration in the Polkadot migration that ran when ref 1143 enacted and upgraded the relay chain, so the end timeslices of the leases are short by about 64 days.This PR adds a migration to fix the Coretime state, which currently includes end timeslices which are incorrect.
Full notes and plan here: https://hackmd.io/kurv6rTXTF6yvaUJ9uSNoQ for work to continue while I'm OOO
try-runtime tests are included in the PR and the HackMD linked above includes steps to manually test the upgrade with chopsticks.