openstack/cinder-specs
Code Issues Proposed changes

Update online-schema-upgrades spec

Browse Source 
This commit updates the spec to add a section on how to enforce the
online data migrations to be completed before running a release that
will fail if they weren't.

Two typo's are also fixed.

Implements: blueprint online-schema-upgrades

Change-Id: I59a5acfd2ba9411c906ae525b66f8a0a1d5b0378
This commit is contained in:
Michał Dulko 2016-01-07 13:09:58 +01:00
parent b1cbb2d496
commit 0718489cc5
1 changed files with 7 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
specs/mitaka/online-schema-upgrades.rst
View File

@ -129,6 +129,11 @@ Now on upgrade we will have M and N release versions. N's versioned objects:
This way we maintain compatibility M->N (N is writing in place M is reading) This way we maintain compatibility M->N (N is writing in place M is reading)
and N->M (M is writing in place N is reading). and N->M (M is writing in place N is reading).
As N is reading from new place, before starting any N's service we need to make
sure that all the CGs are migrated. To enforce that, as a first N's migration
we should merge a dummy one that will block subsequent ones if there are items
that weren't migrated yet.
Please note that we still have old representation in SQLAlchemy model, so we Please note that we still have old representation in SQLAlchemy model, so we
would be unable to drop the column even if we managed to switch N services to would be unable to drop the column even if we managed to switch N services to
write only to the new place. write only to the new place.
@ -145,7 +150,7 @@ remove it from O's versioned object - it will now read and write data only to
the new place. the new place.
After the upgrade we have everything writing and reading only from the new After the upgrade we have everything writing and reading only from the new
place. Moreover - SQLAlchemy models in N's services doesn't have a notion of place. Moreover - SQLAlchemy models in O's services doesn't have a notion of
`volume_type_id` column. Therefore we can have a post-upgrade migration script `volume_type_id` column. Therefore we can have a post-upgrade migration script
that finally drops the column (or we can simply add it as migration in P that finally drops the column (or we can simply add it as migration in P
release if we want to limit number of steps needed to do upgrades. release if we want to limit number of steps needed to do upgrades.
@ -174,7 +179,7 @@ We don't expect impact to the data model itself, but to the way we're doing
migrations of the data model. migrations of the data model.
Changes in the model would need to be reviewed carefully to make sure they Changes in the model would need to be reviewed carefully to make sure they
follow this guidline. follow this guideline.
REST API impact REST API impact
--------------- ---------------