Open nholland94 opened 3 years ago
Being new to OCAML- i am breaking this task into two - This task is broken into 2 parts Update mina_automation to support change of epoch ledger Part 1 https://app.zenhub.com/workspaces/velocity-62264fddc441a100183f7f86/issues/gh/minaprotocol/mina/13520
wait for 2 epochs before we do bootstrap => will need pointers, read existing code for any lead, if not post on slack -> AM Here.
Update test_executive to support epoch ledger for automation Part II https://app.zenhub.com/workspaces/velocity-62264fddc441a100183f7f86/issues/gh/minaprotocol/mina/13521 TASK:
Exit Criteria: Implement above and run test using executive send for Code Review
Part 3 : Integrate as part of nightly run as this will take time to run the tests At present the nightly run has some work to be done, Slack thread conversation has to be sorted . so once Integration framework supports this, will add this test and monitor the stability of the test. This will be created as separate work it.
Does the current hard fork integration test address this issue?
It allows specifying a staking and a next epoch ledger in the test config.
I don't think so? The epoch ledgers set in the HF tests are genesis epoch ledgers which don't get downloaded/synced during boostrap (because a node already has them). We should probably use the same configuration as the HF test (after berkeley
every release will have a HF config) but still test crossing two epochs
Blocked on infra changes to test this on cluster other than mina-integration-test cluster
Create a new test which tests the same properties as the existing bootstrap test, but starts the network in a state that has non-genesis epoch ledgers. Doing this will require adding support to the daemon's configuration to have non-genesis epoch ledgers in the genesis block, and to make the rocksdb instances for those non-genesis ledgers available to the nodes we deploy. To make the epoch ledgers themselves, it should suffice to take the epoch ledger and simulate a few transactions on top of it, taking 2 db snapshots along the way.
Implementing this will meet the acceptance feature requirement for non-genesis epoch ledgers.