Version manager binary

[theodorebugnet]

Description

A version manager that can dispatch different rollup binaries to cover different heights.

Checklist

• Step 1: binary + config
  • Binary that takes a config file with a list of rollup versions (binary path, config path, extra args, migration binary path) + start/stop heights
  • Validates the heights are contiguous (first can be missing start height and last can be missing stop height)
  • Create mock rollup binary that updates a "state" file with height reached, and takes start and stop parameters for this
  • Add tests that manager launches the passed binaries in order
  • If the rollup shuts down for any reason, manager bubbles up the error and shutdown
  • Manager transparently passes signals/SIGTERM to the rollup
• Step 2: upgrade simulator harness
  • Set up a harness that can check out a git repo, build a rollup at multiple commit hashes, and invoke the rollup manager with multiple versions of a binary
  • Cache the built binaries (gitignored)
  • Test resyncing over generated DA data across upgrades
  • Document declarative test case setup
• Step 2: version change detection
  • Query rollup height and/or sequencer ready every ~1s? Ensure rollup height matches expected shutdown height.
  • Ensure we can reliably detect it even on instant finalization.
    • This should be guaranteed with a preferred sequencer, but may be flaky without. The manager will print a special warning if the rollup height is close to, but not at, the expected stop height, and for now this will require manual intervention.
  • Once stop height has been detected, wait for rollup process shutdown, as an exception to bubbling up shutdowns in other cases
  • Update mock-rollup binary to handle HTTP requests
  • Expand integration tests to cover new behaviour and edge cases
• Step 3: testing with load
  • Integrate sov-soak-testing lib into the upgrade simulator
  • Set up a validation test that fails on resync with the latest version, but succeeds with the rollup manager (e.g. chainhash change - verify failure manually)
• Step 4: saving manager state on restart
  • Pass a state file on the CLI and the manager will save the current running version on every upgrade
  • On startup, read the state file and start the rollup from this version, rather than from the first one
  • Integration testing of restarts, using mock-rollup
• Step 5: migration
  • Run the migration script and launch the next version
  • Expand mock-rollup to require migration for its mock state file and add integration testing
• Step 6: ansible/devops adjustments
  • Adjust rollup.sh: we want to pass the same env variables and still set the genesis globally, but launch the version manager and have it pass the config file and extra args (namely start/stop height)
  • Integrate multi-version setup in ansible somehow (multiple binaries and multiple config locations)? This could be left out until the tool manages github repos itself

Future work:

• Have the manager operate on github repos rather than binary paths. Config will specify commit hash per version, manager will check out the repo and build the correct binary itself. Rollup config can come from main repo or separate private repo