This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
Impose new restrictions on paras init and cleanup #4360
Merged
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
pepyakin
added
A0-please_review
apopiak
reviewed
Nov 24, 2021
pepyakin
force-pushed
the
pep-new-constraints
branch
2 times, most recently
from
580a028
to
b947c90
Compare
bkchr
approved these changes
Nov 25, 2021
pepyakin
force-pushed
the
pep-new-constraints
branch
from
b947c90
to
f9f45df
Compare
|
Current dependencies on/for this PR:
This comment was auto-generated by Graphite and will continue to be automatically updated while this PR remains open. |
This was referenced Nov 25, 2021
For upcoming PVF pre-checking feature we will need to impose a couple of new restrictions for: - `schedule_para_initialize`. - `schedule_para_cleanup`. Specifically, for the former we do not want to allow registration of wasm blob that is empty, i.e. 0 bytes. While that currently already does not make a lot of sense, it allows us to simplify the PVF pre-checking logic: if this PR is deployed before the following changes for PVF prechecking then we can be sure that no paras onboarding have to have to go through the PVF pre-checking. In case, we deploy it altogether this property will allow us to distingush paras that came in before PVF pre-checking. For `schedule_para_cleanup` we do not want to allow offboarding of paras that are undergoing the upgrade process. While this is not a harsh restriction this change allows us to avoid making the PVF prechecking more complicated than it has to be.
Now they link to their original declarations in the pallet for more details.
pepyakin
force-pushed
the
pep-new-constraints
branch
from
f9f45df
to
1787632
Compare
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
First PR of the #3211 series.
Related #4322
For upcoming PVF pre-checking feature we will need to impose a couple of
new restrictions for:
schedule_para_initialize.schedule_para_cleanup.Specifically, for the former we do not want to allow registration of
wasm blob that is empty, i.e. 0 bytes. While that currently already
does not make a lot of sense, it allows us to simplify the PVF
pre-checking logic: if this PR is deployed before the following changes
for PVF prechecking then we can be sure that no paras onboarding have to
have to go through the PVF pre-checking. In case, we deploy it
altogether this property will allow us to distingush paras that came in
before PVF pre-checking.
For
schedule_para_cleanupwe do not want to allow offboarding of parasthat are undergoing the upgrade process. While this is not a harsh
restriction this change allows us to avoid making the PVF prechecking
more complicated than it has to be.