aptos-core icon indicating copy to clipboard operation
aptos-core copied to clipboard

[release-tooling] Implement a parser from yaml

Open runtian-zhou opened this issue 2 years ago • 1 comments

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

runtian-zhou avatar Nov 14 '22 23:11 runtian-zhou

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 avatar Nov 16 '22 05:11 runtian-zhou

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?

igor-aptos avatar Nov 16 '22 19:11 igor-aptos

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

runtian-zhou avatar Nov 16 '22 20:11 runtian-zhou

Forge is running suite compat on testnet_2d8b1b57553d869190f61df1aaf7f31a8fc19a7b ==> 1c5a2d849a894ad380bf4befec85f89a8901e141

github-actions[bot] avatar Nov 16 '22 21:11 github-actions[bot]

Forge is running suite land_blocking on 1c5a2d849a894ad380bf4befec85f89a8901e141

github-actions[bot] avatar Nov 16 '22 21:11 github-actions[bot]

:white_check_mark: 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[bot] avatar Nov 16 '22 21:11 github-actions[bot]

:white_check_mark: 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

github-actions[bot] avatar Nov 16 '22 21:11 github-actions[bot]