Repository navigation
feat(upgrade): support hard fork to Dijkstra PV12 - #3748
Merged
Merged
Conversation
Make the target protocol version of upgrade testing configurable via the UPGRADE_PROT_VER env variable (workflow input `upgrade_prot_ver`). It defaults to the base protocol version, i.e. a release upgrade with no hard fork, while UPGRADE_PROT_VER=12 upgrades to Dijkstra for feature branches. - derive cluster and command eras from the protocol versions and switch COMMAND_ERA to the target era after the hard fork - export the base PROTOCOL_VERSION at the start of step3 - enable experimental protocols and hard forks in step3 node configs when the node version is lower than the target protocol version - use the original Dijkstra genesis in step2 and step3 node configs, falling back to the dry-run one when the cluster has none - check the protocol version after the hard fork, so a skipped hard fork test doesn't go unnoticed - apply the same experimental hard forks rule in test_hardfork
The cluster pools are registered before Dijkstra, so they have no BLS keys after the hard fork to Dijkstra PV12. Add `test_register_pools_bls_keys` that runs in step3 right after the hard fork. It generates a BLS key pair for every pool, re-registers the pools with them and puts the keys where the pool start scripts pick them up on the next node start. The nodes are then restarted and the registered keys are checked after the next epoch boundary. Move `reregister_cluster_pool` from the BLS rotation tests to the shared `tests_dijkstra/bls.py` module, so it can be reused.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Make the target protocol version of node upgrade testing configurable, so the upgrade run can also hard fork from Conway PV11 to Dijkstra PV12, e.g. for feature branches.
Target protocol version
upgrade_prot_verinput of theupgradeworkflow (11or12, default11), passed to the runner asUPGRADE_PROT_VER.runner/node_upgrade_pytest.shtakes the target version fromUPGRADE_PROT_VER. It defaults toBASE_PROT_VER, so nightly upgrade runs keep the 11 -> 11 behavior (no hard fork).COMMAND_ERAfollows the era the cluster is in. It switches to the target era after the hard fork unless the user sets it.DijkstraGenesisFile/DijkstraGenesisHashto the configs, reusing the original Dijkstra genesis when there is one.TestDijkstraHardForkAtEpoch = 0while the cluster is still in Conway.ExperimentalProtocolsEnabled/ExperimentalHardForksEnabledare enabled when the node version is lower than the target protocol version (e.g. PV12 with node < 12.0.0).test_hardforkuses the same rule when deciding to skip.test_hardforkdoesn't go unnoticed.BLS keys after the hard fork
The cluster pools are registered in Conway, so they have no BLS keys after the hard fork to Dijkstra. The new
test_register_pools_bls_keysruns in step3 when the target era is Dijkstra:reregister_cluster_poolmoved fromtest_bls_rotation.pytotests_dijkstra/bls.pyso the upgrade test can reuse it. A newallow_xfailarg turns off the xfail on the knownVRFKeyHashAlreadyRegisteredledger issue (ledger#6102). That issue doesn't apply after a hard fork, because the Conway -> Dijkstra translation records the pools' VRF key hashes.Docs
agent_docs/tag_testing.mdnow describes how to set the target protocol version.