Implement agd snapshots export
#9100
Assignees
Labels
Comments
|
removing from upgrade 16 per discussion in mn sustainability meeting. |
mhofman
pushed a commit
that referenced
this issue
Jun 23, 2024
closes: #9100 closes: #9425 ## Description Until we have better layering of the snapshots extensions in cosmos-sdk, this replaces the implementation of the `snapshots export` command to initiate the snapshot creation through our front-running mechanism used for state-sync. Drive-by cleanup of the root command as well to address #9425 ### Security Considerations None, ### Scaling Considerations None ### Documentation Considerations Communicate to validators that we fixed the command and that it's usable as expected with any cosmos chain. ### Testing Considerations Added an integration test since this only modifies the command line handling Manually tested with the following ``` cd packages/cosmic-swingset make scenario2-setup make scenario2-run-chain # wait until there are blocks, then kill agd --home t1/n0 snapshots export rm -rf t1/n0/data/application.db t1/n0/data/agoric # the above removes app state without removing cometbft state as that cannot # be restored easily in a single node chain agd --home t1/n0 snapshot restore $snapshot_height 2 make scenario2-run-chain # verify blocks are being produced ``` ### Upgrade Considerations Since we replace the upstream sdk command handling, any future changes upstream would have to be reflected in the override.
mhofman
pushed a commit
that referenced
this issue
Jun 23, 2024
closes: #9100 closes: #9425 Until we have better layering of the snapshots extensions in cosmos-sdk, this replaces the implementation of the `snapshots export` command to initiate the snapshot creation through our front-running mechanism used for state-sync. Drive-by cleanup of the root command as well to address #9425 None, None Communicate to validators that we fixed the command and that it's usable as expected with any cosmos chain. Added an integration test since this only modifies the command line handling Manually tested with the following ``` cd packages/cosmic-swingset make scenario2-setup make scenario2-run-chain agd --home t1/n0 snapshots export rm -rf t1/n0/data/application.db t1/n0/data/agoric agd --home t1/n0 snapshot restore $snapshot_height 2 make scenario2-run-chain ``` Since we replace the upstream sdk command handling, any future changes upstream would have to be reflected in the override.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the Problem Being Solved?
#7225 and later #8072 implemented state-sync support including SwingSet state by introducing a manual commit sync point in the Cosmos SDK (agoric-labs/cosmos-sdk#297). That approach bypassed the
snapshotcall originally made by the SDK during commit, and instead initiated the swingset side of the snapshot before proceeding to the cosmos side because we couldn't guarantee the timing of the cosmos side and because the snapshot of the swingset side must be initiated before the state has further changed (no support for arbitrary height snapshot).Cosmos 0.46 introduces a
snapshotsCLI command which allows amongst other things, to generate and restore from state-sync snapshots present in the snapshot DB. Unfortunately generating a snapshot (snapshots export) does not work because it doesn't initiate the swingset export as expected.Description of the Design
Either patch the CLI to initiate the swingset export akin to the patch made to the commit time snapshots, or refactor (and upstream) a mechanism for snapshot extensions to hook into the snapshot creation flow, allowing them to initiate work in a blocking way.
Security Considerations
Potential for snapshot extensions to block forward progress if it has erroneous logic
Scaling Considerations
Extension snapshot initiation while blocking should return promptly
Test Plan
Test using
agd snapshotscommands.Integration tests of state-sync (possibly part of #8794)
Upgrade Considerations
None specific to this issue.
The text was updated successfully, but these errors were encountered: