-
Notifications
You must be signed in to change notification settings - Fork 684
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
Runtime: allow backing multiple candidates of same parachain on different cores #3231
Conversation
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
…reim/backing_multiple_cores_per_para
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
…:paritytech/polkadot-sdk into sandreim/runtime_core_index_step1
Seeing this new I think we'll need another NodeFeature bit, This way:
Seeing this, I'm wondering if having this CC @eskimor |
Maybe a |
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
…:paritytech/polkadot-sdk into sandreim/runtime_core_index_step1
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
@alindima |
I thought we wanted to maintain the possibility of not having elastic scaling but still not bricking a parachain which occupies more cores. |
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
This is included in this PR, they won't break if the |
I am talking about after we enable elastic scaling |
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
Anything we implement for elastic scaling must not break parachains that don't make use of this feature, while also not requiring them to upgrade (except of when we add CoreIndex to the commited candidate receipt). We should prevent parachains (I'll cut a ticket) from acquiring multiple cores as a safety measure and as an enablement mechanism. We initially plan to launch on Rococo, while on other chains the possibility of assigning multiple cores is disabled - hence elastic scaling is disabled. |
Signed-off-by: Andrei Sandu <andrei-mihail@parity.io>
alice: js-script ./0012-enable-node-feature.js with "1" return is 0 within 600 seconds | ||
|
||
# Wait two sessions for the config to be updated. | ||
sleep 120 seconds |
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.
It would be better to wait for the actual session change 😬 - If that is not possible right now, we should add that feature.
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 very good @alindima. Left a few nits and a question.
// cases. | ||
if context == ProcessInherentDataContext::Enter { | ||
ensure!( | ||
!dropped_elastic_scaling_candidates, |
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.
Unrelated to this PR but why we check if we have dropped 'elastic scaling candidates' here, but we are fine dropping candidates without assigned core (which happens here)?
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.
Thanks for pointing this out!
prior to this PR, we just assumed that one para maps to one core. So we were only checking if the candidate's paraid has one scheduled core.
if it didn't, we'd return an error. if multiple candidates with the same paraid were supplied, we'd only check for one scheduled core.
The logic I added is more comprehensive and will work for proper elastic scaling also. But I decided to be more lenient and just filter out unscheduled candidates instead of erroring.
However, the check you mentioned should be I think extended to all dropped candidates 👍️ I don't see a reason why it should only be for some of them
because they should be all filtered by the block author. the other block importers should not do this
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.
done
The CI pipeline was cancelled due to failure one of the required jobs. |
…rent cores (#3231) Fixes #3144 Builds on top of #3229 Some preparations for Runtime to support elastic scaling, guarded by config node features bit `FeatureIndex::ElasticScalingMVP`. This PR introduces a per-candidate `CoreIndex` but does it in a hacky way to avoid changing `CandidateCommitments`, `CandidateReceipts` primitives and networking protocols. If the `ElasticScalingMVP` feature bit is enabled then `BackedCandidate::validator_indices` is extended by 8 bits. The value stored in these bits represents the assumed core index for the candidate. It is temporary solution which works by creating a mapping from `BackedCandidate` to `CoreIndex` by assuming the `CoreIndex` can be discovered by checking in which validator group the validator that signed the statement is. TODO: - [x] fix tests - [x] add new tests - [x] Bump runtime API for Kusama, so we have that node features thing! -> polkadot-fellows/runtimes#194 --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> Signed-off-by: alindima <alin@parity.io> Co-authored-by: alindima <alin@parity.io>
…rent cores (#3231) Fixes #3144 Builds on top of #3229 ### Summary Some preparations for Runtime to support elastic scaling, guarded by config node features bit `FeatureIndex::ElasticScalingMVP`. This PR introduces a per-candidate `CoreIndex` but does it in a hacky way to avoid changing `CandidateCommitments`, `CandidateReceipts` primitives and networking protocols. #### Including `CoreIndex` in `BackedCandidate` If the `ElasticScalingMVP` feature bit is enabled then `BackedCandidate::validator_indices` is extended by 8 bits. The value stored in these bits represents the assumed core index for the candidate. It is temporary solution which works by creating a mapping from `BackedCandidate` to `CoreIndex` by assuming the `CoreIndex` can be discovered by checking in which validator group the validator that signed the statement is. TODO: - [x] fix tests - [x] add new tests - [x] Bump runtime API for Kusama, so we have that node features thing! -> polkadot-fellows/runtimes#194 --------- Signed-off-by: Andrei Sandu <andrei-mihail@parity.io> Signed-off-by: alindima <alin@parity.io> Co-authored-by: alindima <alin@parity.io>
…head-data * origin/master: (51 commits) Runtime Upgrade ref docs and Single Block Migration example pallet (#1554) Collator overseer builder unification (#3335) Introduce storage attr macro `#[disable_try_decode_storage]` and set it on `System::Events` and `ParachainSystem::HostConfiguration` (#3454) Add Polkadotters bootnoders per IBP application (#3423) Add documentation around FRAME Origin (#3362) Bridge zombienet tests: Check amount received at destination (#3490) Snowbridge benchmark tests fix (#3424) fix(zombienet): increase timeout in download artifacts (#3376) Cleanup String::from_utf8 (#3446) [prdoc] Validate crate names (#3467) Limit max execution time for `test-linux-stable` CI jobs (#3483) Introduce Notification block pinning limit (#2935) frame-support: Improve error reporting when having too many pallets (#3478) add Encointer as trusted teleporter for Westend (#3411) [pallet-xcm] Adjust benchmarks (teleport_assets/reserve_transfer_assets) not relying on ED (#3464) Add more debug logs to understand if statement-distribution misbehaving (#3419) Remove redundant parachains assigner pallet. (#3457) Use generic hash for runtime wasm in resolve_state_version_from_wasm (#3447) Runtime: allow backing multiple candidates of same parachain on different cores (#3231) Bridge zombienet tests: move all "framework" files under one folder (#3462) ...
Fixes #3144
Builds on top of #3229
Summary
Some preparations for Runtime to support elastic scaling, guarded by config node features bit
FeatureIndex::ElasticScalingMVP
. This PR introduces a per-candidateCoreIndex
but does it in a hacky way to avoid changingCandidateCommitments
,CandidateReceipts
primitives and networking protocols.Including
CoreIndex
inBackedCandidate
If the
ElasticScalingMVP
feature bit is enabled thenBackedCandidate::validator_indices
is extended by 8 bits.The value stored in these bits represents the assumed core index for the candidate.
It is temporary solution which works by creating a mapping from
BackedCandidate
toCoreIndex
by assuming theCoreIndex
can be discovered by checking in which validator group the validator that signed the statement is.TODO: