From 5e2e5c7a046d7ec73c484acb6f577f1da6a9aa40 Mon Sep 17 00:00:00 2001 From: Sean Dague Date: Wed, 21 May 2014 17:26:33 -0400 Subject: [PATCH] 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 --- .../incubation-integration-requirements.rst | 32 +++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/reference/incubation-integration-requirements.rst b/reference/incubation-integration-requirements.rst index 5bf48cd69..2af854e97 100644 --- a/reference/incubation-integration-requirements.rst +++ b/reference/incubation-integration-requirements.rst @@ -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 --