~jujudocs/clouddocs/trunk

Title: Upgrading and Patching - OpenStack

Status: In Progress

 

# Upgrading and Patching - OpenStack

 

## Introduction

 

**TODO**

 

## Scope

 

**TODO**

 

## Upgrading

 

To upgrade an OpenStack cluster in one big step requires additional

hardware to setup and update cloud in addition to the productive one. This leads to a longer

outage while your cloud is in read-only mode, the state is transferred to the new

one, and the environments are switched. The preferred way to upgrade an OpenStack

cloud is the rolling upgrade of each system component, piece by piece.

 

Here you can choose between in-place and side-by-side upgrades. The first one needs

to shutdown the regarding component while you perform the upgrade. Be aware you

may have troubles in case of a rollback. To avoid this, utilize the side-by-side upgrade approach.

 

Before starting the upgrade you should:

 

- Perform some "cleaning" of the environment process to ensure a consistent state. For 

  example, instances not fully purged from the system after deletion may cause 

  indeterminate behavior.

- Read the release notes and documentation.

- Find incompatibilities between your versions.

 

The following upgrade tasks follow the same procedure for each component:

 

1. Configure the new worker.

1. Turn off the current worker. During this time, hide the downtime using a message

   queue or a load balancer.

1. As described earlier, take a backup of the old worker for a rollback.

1. Copy the state of the current to the new worker.

1. Start up the new worker.

 

Now repeat these steps for each worker in an appropriate order. In case of a problem, it

should be easy to rollback as long as the former worker stays untouched. This is,

beside the shorter downtime, the most important advantage of the side-by-side upgrade.

 

The following order for service upgrades seems the most successful:

 

1. Upgrade the OpenStack Identity Service (Keystone).

1. Upgrade the OpenStack Image Service (Glance).

1. Upgrade OpenStack Compute (Nova), including networking components.

1. Upgrade OpenStack Block Storage (Cinder).

1. Upgrade the OpenStack dashboard.

 

These steps look very easy, but are still a complex procedure depending on your cloud

configuration. We recommend having a testing environment with a near-identical

architecture to your production system. This doesn't mean you should use the same

sizes and hardware. This method would be best, but quite expensive. However, there are ways to reduce

the cost.

 

- Use your own cloud. The simplest place to start testing the next version of OpenStack 

  is by setting up a new environment inside your own cloud. This may seem odd—especially 

  the double virtualisation used in running compute nodes—but it's the fastest way to test your configuration.

- Use a public cloud. Especially because your own cloud is unlikely to have sufficient 

  space to scale test to the level of the entire cloud. Consider using a public cloud 

  to test the scalability limits of your cloud controller configuration. Most public 

  clouds bill by the hour, which means it can be inexpensive to perform even a test 

  with many nodes.

- Make another storage endpoint on the same system. If you use an external storage plug-in 

  or shared file system with your cloud, in many cases it's possible to test that it 

  works by creating a second share or endpoint. This will enable you to test the system 

  before entrusting the new version onto your storage.

- Watch the network. Even with small-scale testing, it should be possible to determine 

  if something is going horribly wrong in inter component communication if you 

  look at the network packets and see too many.

 

**TODO** Add more concrete description here.

 

## Patching

 

**TODO**