Backporting OpenStack database migrations

Backporting database migrations to stable/* branches is discouraged by the OpenStack community, largely because we haven't had an agreeable approach to release them. However, I believe OpenStack Nova first implemented the following approach:

  1. One or more "placeholder" migrations are merged to the master branch, at the beginning of a release cycle (early in milestone 1).
  2. A bug fix requiring a database migration is merged to the master branch. The database migration should be written defensively, such that it will have no adverse effect when applied twice.
  3. The bug fix is then backported to a stable/* branch. The migration number is changed to that of the first available migration number in that stable branch (which "conflicts" with a placeholder migration in the master branch).

This process has two outcomes for production deployments, depending on how frequently upgrades are applied.

Deployments chasing the master branch

These deployments run the database migration in the master branch immediately.

They never apply (or need to apply) the identical backported migration.

Deployments hopping between stable/* branches

These deployments run the database migration in the stable/* branch as soon as there is a stable release.

When they are later upgraded to the next named stable/* branch (say, from stable/havana to stable/icehouse, they inevitably run across the identical migration that landed in the master branch (somewhere later in the migration history), but this migration will have no effect, as the desired change has already been applied.

The catch

Upgrading to the latest stable release (from 2014.1.0 to 2014.1.1, for example) must then involve an expectation of running database migrations via db_sync. I don't believe this is a behavior we advocate today, but I believe it should be a standard step in any service-side upgrade process, not just when you're deploying major releases.