[pallet-broker] add extrinsic to reserve a system core without having to wait two sale boundaries #4273
+883
−386
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
|
bot bench substrate-pallet --pallet=pallet_broker --extrinsic=force_reserve |
|
bot bench substrate-pallet --pallet=pallet_broker |
|
bot bench substrate-pallet --pallet=pallet_broker |
added 3 commits
April 24, 2024 17:00
…=dev --target_dir=substrate --pallet=pallet_broker
…=coretime-rococo --runtime_dir=coretime --target_dir=cumulus --pallet=pallet_broker
…=coretime-westend --runtime_dir=coretime --target_dir=cumulus --pallet=pallet_broker
|
The CI pipeline was cancelled due to failure one of the required jobs. |
|
bot clean |
fellowship-merge-bot bot
pushed a commit
to polkadot-fellows/runtimes
that referenced
this pull request
Apr 29, 2024
…ervention (#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]>
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]>
|
bot bench substrate-pallet --pallet=pallet_broker |
added 3 commits
May 29, 2024 12:24
…=dev --target_dir=substrate --pallet=pallet_broker
…=coretime-westend --runtime_dir=coretime --target_dir=cumulus --pallet=pallet_broker
…=coretime-rococo --runtime_dir=coretime --target_dir=cumulus --pallet=pallet_broker
|
bot clean |
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.
This essentially performs three actions:
The caller must ensure that a core is first added, with most relay chain implementations having a delay of two session boundaries until it comes into effect.
Alternatively the extrinsic can be called on a core whose workload can be clobbered from now until the reservation kicks in (the sale period after the next). Any workplan entries for that core at other timeslices should be first removed by the caller.