openstack
/
governance
Code Issues Proposed changes

add upgrade expectations 

While we referenced upgrade in the QA expectations, we didn't yet
have any language on upgrade. Because the CDing upgrade expectation
often comes as a surprise to projects, we should be explicit about
it.

This is intentionally a more "folksy" version of the language, as the
more legalistic version appeared to be generating confusion.

Change-Id: Ic73d490d0ed4841600a00e3433163c3bd93a2660
This commit is contained in:
Sean Dague 2014-05-21 17:26:33 -04:00
parent 5d0bf1908b
commit 5e2e5c7a04
1 changed files with 32 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
reference/incubation-integration-requirements.rst
View File

@ -172,6 +172,38 @@ API
available in the Horizon dashboard, then the project should ensure
that integration exists
Upgrade
-------
Seamless upgradability of OpenStack components remains the most
requested feature by deployers and operators. Once a deployer of
OpenStack has installed a cloud, there is an implicit expectation that
it can be upgraded in place on the existing hardware without creating
downtime for any of the active resources that the cloud manages.
Note: at this point in time we still consider it acceptable to require
downtime of the API / control plane for upgrade, though encourage
projects to develop ways to reduce or eliminate that need.
As such, we expect projects to have a path for inplace upgrading from:
* one stable release to the next stable release (i.e. stable/havana =>
stable/icehouse)
* from the most recent stable branch to upstream master
(i.e. stable/icehouse => master during the Juno development cycle)
* within points in master (i.e. from a commit that merged to the
master branch two weeks ago, to the latest commit on the master
branch). This is for supporting deployers who wish to continuously
deploy their OpenStack clouds.
This requirement becomes relevant after the first stable release that
a project ships in, however projects are encouraged to incorporate a
culture of upgradability early in their project lifecycle.
In place upgrade also applies when migrating functionality out of one
project into another, as in nova-volume => cinder, nova-network =>
neutron, nova-baremetal => ironic, and/or nova-scheduler -> gantt.
QA
--