[pallet-broker] add extrinsic to reserve a system core without having to wait two sale boundaries #4273
Conversation
|
bot bench substrate-pallet --pallet=pallet_broker --extrinsic=force_reserve |
|
bot bench substrate-pallet --pallet=pallet_broker |
|
bot bench substrate-pallet --pallet=pallet_broker |
…=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 |
…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]>
…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 |
…=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 |
|
@al3mart this is the PR I was talking about, this functionality might fit better in the |
Not sure we need a new pallet for this. We can just add the functionality here. I know that this sudo wrapper exists in the relay chain, but the lines are very very blurry and we also have some duplicated functions etc. Just more confusing than what it helps IMO. |
|
@seadanda let's get this merged. |
|
OK cool, I've got some other functionality in mind that I can spec out in an issue |
|
All GitHub workflows were cancelled due to failure one of the required jobs. |
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.