Adding upgrade file watcher for cosmovisor. Currently the comswisor upgrade mechanism relays on parsing log messages. This is not reliable: + depends on the log level output (x/upgrade uses INFO) + can be hacked by accidentally logging user user content + can be broken by using upgrade name which will break the regex pattern. closes: #7703 closes: #8523 closes: #8651 closes: #8793 closes: #8964 **Depends on**: - #9652 --- Before we can merge this PR, please make sure that all the following items have been checked off. If any of the checklist items are not applicable, please leave them but write a little note why. - [ ] Targeted PR against correct branch (see [CONTRIBUTING.md](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#pr-targeting)) - [ ] Linked to Github issue with discussion and accepted design OR link to spec that describes this work. - [ ] Code follows the [module structure standards](https://github.com/cosmos/cosmos-sdk/blob/master/docs/building-modules/structure.md). - [ ] Wrote unit and integration [tests](https://github.com/cosmos/cosmos-sdk/blob/master/CONTRIBUTING.md#testing) - [ ] Updated relevant documentation (`docs/`) or specification (`x/<module>/spec/`) - [ ] Added relevant `godoc` [comments](https://blog.golang.org/godoc-documenting-go-code). - [ ] Added a relevant changelog entry to the `Unreleased` section in `CHANGELOG.md` - [ ] Re-reviewed `Files changed` in the Github PR explorer - [ ] Review `Codecov Report` in the comment section below once CI passes |
||
---|---|---|
.. | ||
01_concepts.md | ||
02_state.md | ||
03_events.md | ||
README.md |
README.md
upgrade
Abstract
x/upgrade
is an implementation of a Cosmos SDK module that facilitates smoothly
upgrading a live Cosmos chain to a new (breaking) software version. It accomplishes this by
providing a BeginBlocker
hook that prevents the blockchain state machine from
proceeding once a pre-defined upgrade block height has been reached.
The module does not prescribe anything regarding how governance decides to do an upgrade, but just the mechanism for coordinating the upgrade safely. Without software support for upgrades, upgrading a live chain is risky because all of the validators need to pause their state machines at exactly the same point in the process. If this is not done correctly, there can be state inconsistencies which are hard to recover from.