Add migrations to onboard people immediately and tidy up previous intervention #286
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
10 tasks
joepetrowski
approved these changes
Apr 25, 2024
eskimor
approved these changes
Apr 26, 2024
|
/merge |
fellowship-merge-bot
bot
merged commit 374e092
into
polkadot-fellows:main
42 checks passed
|
Enabled Available commands
For more information see the documentation |
seadanda
added a commit
to seadanda/runtimes
that referenced
this pull request
Apr 29, 2024
…ervention (polkadot-fellows#286) When calling the reserve extrinsic after sales have started, the assignment will be reserved, but two sale period boundaries must pass before the core is actually assigned. Since this can take between 28 and 56 days on production networks, a new extrinsic is introduced to shorten the timeline at the "cost" of more weight in paritytech/polkadot-sdk#4273. This essentially performs four actions: 1. Add an additional core for the new reservation 2. Reserve it (applies after two sale boundaries) 3. Add it to the Workplan for the next sale period 4. Add it to the Workplan for the rest of the current sale period To allow a quick People Chain onboarding on Kusama, a migration is introduced here which does the same thing without needing to wait for a release and to upgrade the runtimes repo. Another migration is added to clean up an outdated assignment in state from the old sale start before the leases were added. This avoids the first lease (parachain 2000) losing its core to the new pool core a few days before it is given one again with the new timeline at the end of the new sale period 0. --------- Co-authored-by: joe petrowski <[email protected]>
fellowship-merge-bot bot
pushed a commit
that referenced
this pull request
Apr 29, 2024
Cherry pick #286 onto the 1.2.2 release for a clean 1.2.3 release. This release is the one proposed in #288 The changelog from main is clipped to only include the relevant changes from the cherry picked commit. - A migration is added to onboard the people chain without the usual two sale boundary delay that came with the shift to coretime. - Another migration is added to clean up an outdated assignment in state from the old sale start before the leases were added. More info in the changelog of this PR and PR #286. - [ ] Does not require a CHANGELOG entry --------- Co-authored-by: joe petrowski <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When calling the reserve extrinsic after sales have started, the assignment will be reserved, but two sale period boundaries must pass before the core is actually assigned.
Since this can take between 28 and 56 days on production networks, a new extrinsic is introduced to shorten the timeline at the "cost" of more weight in paritytech/polkadot-sdk#4273.
This essentially performs four actions:
To allow a quick People Chain onboarding on Kusama, a migration is introduced here which does the same thing without needing to wait for a release and to upgrade the runtimes repo.
Another migration is added to clean up an outdated assignment in state from the old sale start before the leases were added. This avoids the first lease (parachain 2000) losing its core to the new pool core a few days before it is given one again with the new timeline at the end of the new sale period 0.