Add a new section: "Upgrade impact" to the template

Code Issues Proposed changes

We don't have a dedicated section for discussing potential upgrade
impact of changes and adding one might help authors to think about
and document upgrade implications in their specs.
Co-Authored-By: Matt Riedemann <mriedem.os@gmail.com>
Change-Id: I1798f2bdb246af9b9b12dbe9276d0a68a82e4c88

This commit is contained in:

melanie witt

2017年04月13日 20:33:13 +00:00

committed by Matt Riedemann

parent 2c3c027526

commit be10d16ac3

1 changed files with 28 additions and 0 deletions

Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL

Download Patch File Download Diff File Expand all files Collapse all files

28
specs/queens-template.rst

View File

@@ -289,6 +289,34 @@ such as:

* If the blueprint proposes a change to the driver API, discussion of how

other hypervisors would implement the feature is required.

Upgrade impact

--------------

Describe any potential upgrade impact on the system, such as:

* If this change adds a new feature to the compute host that the controller

services rely on, the controller services may need to check the minimum

compute service version in the deployment before using the new feature. For

example, in Ocata, the FilterScheduler did not use the Placement API until

all compute services were upgraded to at least Ocata.

* While we strive to have feature parity between all virt drivers, it is not

uncommon for one virt driver to implement a new feature exposed out of the

API before the others. For example, extending the size of an attached

volume. Since Nova does not yet have any type of sophisticated *capabilities*

API so a user can know what actions can be performed on a given instance,

consider adding a new policy rule to at least let operators that cannot

support a virt-specific feature disable it in their cloud which is at least

presented to the user in an understandable way by getting a ``403 Forbidden``

error.

* Nova supports N-1 version *nova-compute* services for rolling upgrades. Does

the proposed change need to consider older code running that may impact how

the new change functions, for example, by changing or overwriting global

state in the database? This is generally most problematic when making changes

that involve multiple compute hosts, like move operations such as migrate,

resize, unshelve and evacuate.

Implementation

==============

Add a new section: "Upgrade impact" to the template

28 specs/queens-template.rst Unescape Escape View File

28
specs/queens-template.rst

View File