-
Notifications
You must be signed in to change notification settings - Fork 721
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
[pallet-broker] add extrinsic to reserve a system core without having to wait two sale boundaries #4273
base: master
Are you sure you want to change the base?
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 |
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.