Summary

Ref: #8889

Problem Definition

Users want upgrades to be as pain-free as possible. The objective is to introduce changes to the config which allow seamless upgrades. Tendermint should avoid as much as possible to make changes to the config that unexpectedly change the behaviour of the node operator. In the case it must, a sane error should help the node operator to manually alter the field necessary.

Current Mechanism

The way Tendermint currently handles config files is strictly read-only. In the case of a new binary, Tendermint will try to read in the values it recognises and set the values it doesn't with their respective default. It uses Viper to do this. Each config parameter always has a default so an incomplete config file will never error.

In the case of a new field say discard_abci_responses. If it doesn't exist in the config, it will take the default value (false in this case to maintain consistency). Because Tendermint never writes the changes, the user will not be made aware of it in the config.

In the case of removing fields, Tendermint doesn't write to the config so the fields remain there even although they are now ignored. This may confuse users into thinking they are still used.

Renaming fields can be seen as a combination of removing and adding a new field.

Proposal

I propose to add a version field at the top of the config. This will make it easy to recognise what binary wrote the config and thus how a different binary can safely upgrade it if necessary. I would propose that the version correlates to the Tendermint version of the binary i.e. 0.37.0

Second, I propose to also add a boolean field automatic_upgrades. If set to true, the user is expressly giving permission for Tendermint binaries to write to the config else Tendermint will try to read only. We can use the confix tool Michael wrote or the golang template engine (depending if we want to write the entire file or replace individual lines)