不知道其他软件有没有类似的指导原则。
Theory of Upgrade
Grenade works under the following theory of upgrade.
- New code should work with old configs（新代码兼容旧的配置）
The upgrade process should not require a config change to run a new release. All config behavior is supposed to be deprecated over a release cycle, so that upon release new code works with the last releases configs. Those configs may create deprecation warnings which need to be addressed before the next release, but they should still work and largely have the same behavior.
- New code should need nothing more than 'db migrations' （新代码只需要考虑db迁移）
Clearly the release of new code may include new database models. Standard upgrade procedure is to turn off all services that touch the database, run the db migration script, and start with new code.
- Resources created by services before upgrade, should still be there after the system is upgraded （服务创建的资源，在系统升级后，应继续存在）
When upgrading Nova you expect all your VMs to still function during the entire upgrade (whether or not Nova services are up). Taking down the control plane should not take down your VMs.
- Any other required changes on upgrade are an exception and must be called out in the release notes. （升级过程中其他作为特例的改变要求， 必须出现在发行说明中）
Grenade supports per release specific upgrade scripts (from-juno, from-kilo). These are designed to support upgrades where additional manual steps are needed for a specific upgrade (i.e. from juno to kilo). These should be used sparingly.
The Grenade core team requires the following before landing these kinds of changes:
- The Release Notes for the release where this will be required clearly specify these manual upgrade steps.
- The PTL for the project in question has signed off on this change.