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

[release-tooling] Implement a parser from yaml #5562

Merged
merged 3 commits into from
Nov 16, 2022

Conversation

runtian-zhou
Copy link
Contributor

@runtian-zhou runtian-zhou commented Nov 14, 2022

Description

Implement the parser to parse the release config from a yaml file. Added generation logic for consensus config as well.

Test Plan

cargo run -- write-default --output-path data/example.yaml

and cargo run -- generate-proposals --release-config data/example.yaml --output-dir <OUTPUT_DIR>

The upgrade smoke test will make sure upgrading consensus config would work as well.


This change is Reviewable

use aptos_types::on_chain_config::OnChainConsensusConfig;
use move_model::{code_writer::CodeWriter, emit, emitln, model::Loc};

pub fn generate_consensus_upgrade_proposal(
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This logic is migrated from #5527. Maybe we could refactor that test later cc @igor-aptos

@@ -0,0 +1,472 @@
---
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is an example release config that contains all the information we could set using on chain config. Governance proposals could be generated automatically from this yaml file.

@runtian-zhou runtian-zhou force-pushed the runtianz/release_config branch from 89fd2a4 to 20e7d03 Compare November 15, 2022 20:00

emitln!(writer, "// Consensus config upgrade proposal\n");

if is_testnet {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: This is getting a bit redundant. Refactor this so each component doesn't have to do this themselves?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yea I think I can refactor a bit here.


pub fn parse(serialized: &str) -> Result<Self> {
serde_yaml::from_str(serialized).map_err(|e| anyhow!("Failed to parse the config: {:?}", e))
}
}

impl Default for ReleaseConfig {
fn default() -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you remind me where this is used again?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is used in the upgrade test to make sure that the proposal generation process would always work. Though in the future we should be replacing this with the real release config we want to put for the next release cycle.

Copy link
Contributor

Choose a reason for hiding this comment

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

"in the future we should be replacing this with the real release config we want to put for the next release cycle." => What do you mean? Isn't this the default only?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sry I mean that right now, we use ReleaseConfig::default in the testing pipeline. We should expect to see another test that uses sth like ReleaseConfig::upcoming_release to make sure the config is indeed valid. Hope that makes sense.

Copy link
Contributor

@zekun000 zekun000 left a comment

Choose a reason for hiding this comment

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

oh this is really nice to have

@runtian-zhou
Copy link
Contributor Author

Updated the PR with the refactor. Tho it doesn't look cleaner than before either... lemme know if you would like to keep it or not cc @movekevin

@runtian-zhou runtian-zhou force-pushed the runtianz/release_config branch from 20e7d03 to 83b05bb Compare November 16, 2022 05:34
@runtian-zhou runtian-zhou force-pushed the runtianz/release_config branch from 83b05bb to 1c5a2d8 Compare November 16, 2022 07:28
@igor-aptos
Copy link
Contributor

This is probably beyond this PR, but what is the expected flow?

It seems to me release yaml is already materialized release decision - delta between two versions, i.e. what needs to be upgraded, for a specific network (i.e. testnet or not). Correct?
How are we going to generate all release yamls for a single release, for all the networks we have? (devnet, testnet, mainnet)

I.e. how would we know if any configs have changed, and whether governance proposal for updating onchain config (for example consensus one) is going to be needed?

Are we going to have a separate "snapshot" files telling us the state of various networks, and then create a snapshot for new release, and then create there release yamls as a delta between snapshots, for each of the networks?

@runtian-zhou
Copy link
Contributor Author

Right now the PR only did the generation from yaml path. In the next PR I can add the logic to fetch the config from rest endpoint and compare it against the yaml file. cc @igor-aptos

Copy link
Contributor

@igor-aptos igor-aptos left a comment

Choose a reason for hiding this comment

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

makes sense, just wanted to understand where this fits in.

base_path: &Path,
is_testnet: bool,
) -> Result<()> {
pub fn generate_release_proposal_scripts(&self, base_path: &Path) -> Result<()> {
let mut result = vec![];
Copy link
Contributor

Choose a reason for hiding this comment

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

you are not returning the result, or doing anything else with it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This function will generate a set of move scripts into the base_path.

@runtian-zhou runtian-zhou enabled auto-merge (squash) November 16, 2022 20:59
@github-actions

This comment has been minimized.

@github-actions

This comment has been minimized.

@github-actions
Copy link
Contributor

✅ Forge suite compat success on testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 1c5a2d849a894ad380bf4befec85f89a8901e141

Compatibility test results for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 1c5a2d849a894ad380bf4befec85f89a8901e141 (PR)
1. Check liveness of validators at old version: testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b
compatibility::simple-validator-upgrade::liveness-check : 7362 TPS, 5222 ms latency, 7200 ms p99 latency,no expired txns
2. Upgrading first Validator to new version: 1c5a2d849a894ad380bf4befec85f89a8901e141
compatibility::simple-validator-upgrade::single-validator-upgrade : 4828 TPS, 8210 ms latency, 11200 ms p99 latency,no expired txns
3. Upgrading rest of first batch to new version: 1c5a2d849a894ad380bf4befec85f89a8901e141
compatibility::simple-validator-upgrade::half-validator-upgrade : 4476 TPS, 8927 ms latency, 11400 ms p99 latency,no expired txns
4. upgrading second batch to new version: 1c5a2d849a894ad380bf4befec85f89a8901e141
compatibility::simple-validator-upgrade::rest-validator-upgrade : 6813 TPS, 5642 ms latency, 10400 ms p99 latency,no expired txns
5. check swarm health
Compatibility test for testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 1c5a2d849a894ad380bf4befec85f89a8901e141 passed
Test Ok

@github-actions
Copy link
Contributor

✅ Forge suite land_blocking success on 1c5a2d849a894ad380bf4befec85f89a8901e141

performance benchmark with full nodes : 6642 TPS, 5973 ms latency, 17300 ms p99 latency,(!) expired 880 out of 2837080 txns
Test Ok

@runtian-zhou runtian-zhou merged commit 620a809 into main Nov 16, 2022
@runtian-zhou runtian-zhou deleted the runtianz/release_config branch November 16, 2022 21:41
areshand pushed a commit to areshand/aptos-core-1 that referenced this pull request Dec 18, 2022
* [release-builder] Implement a parser for the framework release config

* [release-builder] Add consensus config to release config

* [release-tooling] Refactor the common logic for generating proposal.
runtian-zhou added a commit that referenced this pull request Dec 20, 2022
* [release-builder] Implement a parser for the framework release config

* [release-builder] Add consensus config to release config

* [release-tooling] Refactor the common logic for generating proposal.
runtian-zhou added a commit that referenced this pull request Jan 3, 2023
…mainnet (#5936)

* [release-tooling] Implement a parser from yaml (#5562)

* [release-builder] Implement a parser for the framework release config

* [release-builder] Add consensus config to release config

* [release-tooling] Refactor the common logic for generating proposal.

* [release tooling] multi-step proposal release tooling (#5834)

Co-authored-by: chloeqjz <[email protected]>

* [aptos-release-tooling] Add an option to compare release binary with on chain configs (#5796)

* [aptos-release-tooling] Add an option to compare release binary with on chain configs

* fixup! [aptos-release-tooling] Add an option to compare release binary with on chain configs

Co-authored-by: 0xchloe <[email protected]>
Co-authored-by: chloeqjz <[email protected]>
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