openstack/openstack-manuals
Code Issues Proposed changes
8760c94427
openstack-manuals/doc/arch-design-draft/source/operator-requirements-upgrades.rst
daz bc05b757da [arch-design-draft] Reorganise operators requirements chapter 
1. Split sections into separate files
2. Consolidate hardware content from the current guide
3. Consolidate software content from the current guide

Change-Id: I5edf204d88ea5622c656fe58699260e31fb9b7d3
Implements: blueprint arch-guide-mitaka-reorg
2016-01-18 15:09:13 +01:00

2.0 KiB
Raw Blame History

Upgrades

Running OpenStack with a focus on availability requires striking a balance between stability and features. For example, it might be tempting to run an older stable release branch of OpenStack to make deployments easier. However known issues that may be of some concern or only have minimal impact in smaller deployments could become pain points as scale increases. Recent releases may address well known issues. The OpenStack community can help resolve reported issues by applying the collective expertise of the OpenStack developers.

In multi-site OpenStack clouds deployed using regions, sites are independent OpenStack installations which are linked together using shared centralized services such as OpenStack Identity. At a high level the recommended order of operations to upgrade an individual OpenStack environment is (see the Upgrades chapter of the Operations Guide for details):

  1. Upgrade the OpenStack Identity service (keystone).
  2. Upgrade the OpenStack Image service (glance).
  3. Upgrade OpenStack Compute (nova), including networking components.
  4. Upgrade OpenStack Block Storage (cinder).
  5. Upgrade the OpenStack dashboard (horizon).

The process for upgrading a multi-site environment is not significantly different:

  1. Upgrade the shared OpenStack Identity service (keystone) deployment.
  2. Upgrade the OpenStack Image service (glance) at each site.
  3. Upgrade OpenStack Compute (nova), including networking components, at each site.
  4. Upgrade OpenStack Block Storage (cinder) at each site.
  5. Upgrade the OpenStack dashboard (horizon), at each site or in the single central location if it is shared.

Compute upgrades within each site can also be performed in a rolling fashion. Compute controller services (API, Scheduler, and Conductor) can be upgraded prior to upgrading of individual compute nodes. This allows operations staff to keep a site operational for users of Compute services while performing an upgrade.