Skip to content
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

Enable elastic scaling node side feature on Polkadot #340

Conversation

sandreim
Copy link
Contributor

@sandreim sandreim commented Jun 3, 2024

This feature is needed on Polkadot to ensure parachains can still make progress if they have multiple cores assigned. Relay chain support for elastic scaling is implemented but requires bumping polkadot-runtime-parachains crate version to at least 11.0.0 which will happen later.

  • Does not require a CHANGELOG entry

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>
pub struct EnableElasticScalingNodeFeature;
impl OnRuntimeUpgrade for EnableElasticScalingNodeFeature {
fn on_runtime_upgrade() -> Weight {
let _ = Configuration::set_node_feature(RawOrigin::Root.into(), 1, true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are we not using the constant?

Copy link
Contributor Author

@sandreim sandreim Jun 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's currently in staging (based on current crate version usage), felt that we don't want to use any of the staging stuff here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm - don't we have v7 already in the current release? In any case, seems like we would be using staging stuff anyways, just hiding it by using a magic number? Also I think this can wait for the next polkadot-sdk release, where this should be v7 then.

Copy link
Contributor Author

@sandreim sandreim Jun 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That makes sense, but this needs to go in same or before release with core time.

@eskimor
Copy link
Contributor

eskimor commented Jun 17, 2024

@sandreim Let's rebase on this one.

@eskimor
Copy link
Contributor

eskimor commented Jun 17, 2024

@sandreim Let's rebase on this one.

Actually, ignore. I can just make this part of my coretime enabling PR while I am already at it.

Copy link
Contributor

@bkchr bkchr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we again try to set some configuration option, that could just be a separate referendum? :P

Please close and just open a referendum on chain.

@alindima
Copy link
Contributor

Do we again try to set some configuration option, that could just be a separate referendum? :P

Please close and just open a referendum on chain.

I think the reasoning of doing this as a migration was that it's more of a bugfix than a new feature. Once coretime is enabled on polkadot, if this feature bit is not set, one para that gets scheduled on two cores will brick itself.

@bkchr
Copy link
Contributor

bkchr commented Jun 17, 2024

I think the reasoning of doing this as a migration was that it's more of a bugfix than a new feature.

This can already be opened today and ready before Coretime lands on Polkadot. Not really an argument to put this into a runtime upgrade.

We have done it here using a runtime upgrade, because the feature was added in the same release AFAIR. However, this is not the case anymore.

@sandreim
Copy link
Contributor Author

@sandreim sandreim closed this Jul 19, 2024
@sandreim sandreim deleted the sandreim/elastic_scaling_feature_polkadot branch July 19, 2024 14:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants