Add Upgrade impact section to the spec template

It happens that we overlook the upgrade impact of some new
features. Add Upgrade impact section to the spec template to make us
think about how do we upgrade to some feature when proposing that
feature.

Change-Id: I137a4353ce73ae961e83ecd656df77d6bd45a4e4
This commit is contained in:
Jiri Stransky 2018-08-02 16:17:36 +02:00
parent 29c978f328
commit f478d2fc01
1 changed files with 23 additions and 8 deletions

View File

@ -91,6 +91,29 @@ guidelines are a work in progress and are designed to help you identify
security best practices. For further information, feel free to reach out
to the OpenStack Security Group at openstack-security@lists.openstack.org.
Upgrade Impact
--------------
Describe potential upgrade impact on the system.
* Is this change meant to become the default for deployments at some
point in the future? How do we migrate existing deployments to that
feature?
* Can the system be upgraded to this feature using the upgrade hooks
provided by the composable services framework?
* Describe any plans to deprecate configuration values or
features. (For example, if we change the directory name that
instances are stored in, how do we handle instance directories
created before the change landed? Do we move them? Do we have a
special case in the code? Do we assume that the operator will
recreate all the instances in their cloud?)
* Please state anything that operators upgrading from the previous
release need to be aware of. Do they need to perform extra manual
operations?
Other End User Impact
---------------------
@ -122,14 +145,6 @@ that have not already been mentioned, such as:
* Is this a change that takes immediate effect after its merged, or is it
something that has to be explicitly enabled?
* Please state anything that those doing continuous deployment, or those
upgrading from the previous release, need to be aware of. Also describe
any plans to deprecate configuration values or features. For example, if we
change the directory name that instances are stored in, how do we handle
instance directories created before the change landed? Do we move them? Do
we have a special case in the code? Do we assume that the operator will
recreate all the instances in their cloud?
Developer Impact
----------------