Prototype versioned app module rolling upgrades #3625
Comments
evan-forbes
added
WS: Maintenance 🔧
evan-forbes
changed the title
evan-forbes
added
the
needs:discussion
|
What I basically had in mind is a multiplexer which adheres to the ABCI interface at one end and proxies calls to the relevant state machine. In a way it can be seen as a sort of middleware. Each state machine is responsible for the mechanism they have for bumping the app version. The multiplexer simply stores it to disk somewhere and listens for changes via |
|
As a minimal prototype, I had thought of creating a fork, bumping to v3 and having the wrapper import v1 and v2 of celestia-app. In the future we may want to go.mod these state machines for more fine granularity imports, but to start with I think we can leave it as is and see what kind of binary size that gives us. |
|
Callum shared https://www.notion.so/celestiaorg/Multiapp-Prototype-16865f0eb94546ca8069bdb5e5cadd30 which is super helpful |
evan-forbes
removed
the
needs:discussion
|
The prototype in #3729 works but it took several short-term workarounds that need long-term fixes before merging. |
rootulp
added
WS: V4
and removed
WS: V3 3️⃣
|
Closing this as done b/c the prototype works. I'll create follow-up issues to production-ize the prototype. |
|
Opened #3991 |
We are attempting to gather more information on a flexible and simpler approach to rolling upgrades and also single binary syncs. This approach involves versioning the application struct (and potentially the rest of our modules) in some fashion so that at an upgrade height, it can be swapped out with a different go moduled version of the app.
In theory, for state machine upgrades, this results in something similar to restart upgrades in that we can make arbitrary consensus breaking changes (such as importing a semver minor bump but still consensus breaking version of IBC) while not having to reconnect to peers or completely reload the DB indexed into memory.
AC
To close this issue, we should create a prototype that takes a similar approach to the above to perform a rolling upgrade over 4 nodes in knuu. Ideally there is also a migration included in this upgrade.
The text was updated successfully, but these errors were encountered: