pd: support state tarball for joining nodes #3841
Comments
|
What's the advantage of doing this rather than providing a |
|
As I understand it, that's what the snapshot is: a compressed version of the rocksdb info that pd uses. It must also include a genesis file, which is not included in the pd home directory, but easy enough to overwrite when generating new configs. This ticket is essentially describing the need and the mechanism to "provide a .tar.xz of the pd home directory." |
conorsch
changed the title
|
Got it, I was confused by the term "snapshot" because CometBFT has a notion of p2p snapshot exchange, which we're not currently using. |
|
Thanks, edited for clarity, |
|
Setting this to P-high since this is a requirement to perform a testnet upgrade (both for compaction and migrations) and must be assigned during sprint planning |
|
@erwanor I'll grab this one and give it a shot, trying to parallelize the work with what you've already got in flight on the upgrades front. |
Ah, still more to go. Working on this today. |
Adds documentation for the specific steps to be performed by a node operator in order to participate in a chain upgrade. These docs are largely based on the existing wiki notes [0], adapted for a generalized Penumbra setup. Similarly, sketched out some corresponding changes to the `pd testnet join` docs, but left them commented out for now: those docs are only relevant for joining a chain that has already been upgraded. If things go well with #4087, we'll uncomment those docs and start using them. Finishes and therefore closes #3841. [0] https://github.com/penumbra-zone/penumbra/wiki/Performing-upgrades
Adds documentation for the specific steps to be performed by a node operator in order to participate in a chain upgrade. These docs are largely based on the existing wiki notes [0], adapted for a generalized Penumbra setup. Similarly, sketched out some corresponding changes to the `pd testnet join` docs, but left them commented out for now: those docs are only relevant for joining a chain that has already been upgraded. If things go well with #4087, we'll uncomment those docs and start using them. Finishes and therefore closes #3841. [0] https://github.com/penumbra-zone/penumbra/wiki/Performing-upgrades
Adds documentation for the specific steps to be performed by a node operator in order to participate in a chain upgrade. These docs are largely based on the existing wiki notes [0], adapted for a generalized Penumbra setup. Similarly, sketched out some corresponding changes to the `pd testnet join` docs, but left them commented out for now: those docs are only relevant for joining a chain that has already been upgraded. If things go well with #4087, we'll uncomment those docs and start using them. Finishes and therefore closes #3841. [0] https://github.com/penumbra-zone/penumbra/wiki/Performing-upgrades
When chain upgrades are performed (#1804), pd state may be collapsed by a migration, such that late-joining nodes (i.e. nodes that join the network after the upgrade boundary has passed) will not be able to verify historical state. To support late-joining nodes, we must provide the capability for
pd testnet jointo accept compressed archives of historical pd state, and use them during bootstrapping.Proposal: add new optional flag
--archive-url=<URL>topd testnet join. Doing so will allow late-joining nodes to pull down a compressed archive from a remote URL, and extract that archive as starting state for pd.Specifically, this requires:
~/.penumbra/testnet_data/node0/pd"). My understanding is we'll need at least 1) rocks db and 2) genesis file in all cases.pd testnet join --archive-url <url>- feat(pd): support archives for migrate and join #4055The text was updated successfully, but these errors were encountered: