docs: clarify chain upgrade procedure #4245
Conversation
cratelyn
added
A-docs
| && cp ~/.penumbra/testnet_data/node0/pd-exported-state/priv_validator_state.json ~/.penumbra/testnet_data/node0/cometbft/data/priv_validator_state.json` | ||
| 8. Then we clean up the old CometBFT state: `find ~/.penumbra/testnet_data/node0/cometbft/data/ -mindepth 1 -maxdepth 1 -type d -exec rm -r {} +` | ||
| 6. Move the migrated state into place: `rm -r ~/.penumbra/testnet_data/node0/pd/rocksdb && mv ~/.penumbra/testnet_data/node0/pd-exported-state/rocksdb ~/.penumbra/testnet_data/node0/pd/` | ||
| 7. Move the new cometbft genesis into place: `cp ~/.penumbra/testnet_data/node0/pd-exported-state/genesis.json ~/.penumbra/testnet_data/node0/cometbft/config/genesis.json` |
There was a problem hiding this comment.
You must reset the comet WAL, blockstore, and evidence DB
There was a problem hiding this comment.
Comet won't start if you don't do the WAL/blockstore, and it will corrupt your state if you don't do the evidence db if i recall correctly
There was a problem hiding this comment.
Thanks for explaining. Substantively, that means we should recommend either:
find ~/.penumbra/testnet_data/node0/cometbft/data/ -mindepth 1 -maxdepth 1 -type d -exec rm -r {} +, as before; orcometbft --home ~/.penumbra/testnet_data/node0/cometbft/ reset-state
AIUI, the two are functionally equivalent. If so, I'd prefer to recommend the latter.
There was a problem hiding this comment.
I think reset-state is what we want, I can test it later today
There was a problem hiding this comment.
We should check that it doesn't delete the indexing KV, will check
There was a problem hiding this comment.
See testing report below, @erwanor. I believe the revised docs are what we need, but would certainly appreciate a +1 from you!
|
Following up on review comments in #4245 (comment), I did some local testing. Findings
MethodologyI grabbed a state dir from a preexisting node, backed it up via tar (so testing was replicable), and re-extracted it to multiple locations: 1) the pristine state, untouched, for a control group; 2) a target for the terminal session showing comparisonsBased on that info, I'm fine recommending the |
conorsch
force-pushed
the
1812-upgrade-docs
branch
from
21af024
to
dbc9ea3
Compare
conorsch
force-pushed
the
1812-upgrade-docs
branch
from
dbc9ea3
to
38d2359
Compare
|
@conorsch |
conorsch
force-pushed
the
1812-upgrade-docs
branch
from
38d2359
to
6f6ba68
Compare
For clarity's sake, that's not a regression: the original |
Follow-up to #4097. We performed a chain upgrade on Penumbra for v0.71.0. Based on feedback from the community validators, we've refined the procedure somewhat. Substantive changes to the docs are as follows: * backup the entire pd & cometbft data dirs, as a precaution * upgrade to new pd early, prior to running export, for simplicity's sake * only move the exported rocksdb directory, which allows preservation of other dirs in pd state, e.g. acme tls info * do not reset priv validator state * amend custom find command to preserve `tx_index.db` Not yet included in these docs are specifics about the upcoming release; we'll add those soon. Finishes and therefore closes #1812.
conorsch
force-pushed
the
1812-upgrade-docs
branch
from
6f6ba68
to
9621537
Compare
We recently removed mention of zeroing-out `priv_validator_state.json` for CometBFT as part of the chain upgrade docs. During migration testing on a private fork today, though, several of us observed that without this change, the network would not resume. More research required to understand the root cause here. Refs #4245, #4239.
We recently removed mention of zeroing-out `priv_validator_state.json` for CometBFT as part of the chain upgrade docs. During migration testing on a private fork today, though, several of us observed that without this change, the network would not resume. More research required to understand the root cause here. Refs #4245, #4239.
Describe your changes
Follow-up to #4097. We performed a chain upgrade on Penumbra for v0.71.0. Based on feedback from the community validators, we've refined the procedure somewhat. Substantive changes to the docs are as follows:
tx_index.dbNot yet included in these docs are specifics about the upcoming release; we'll add those soon.
Finishes and therefore closes #1812.
Issue ticket number and link
Checklist before requesting a review
If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: