Clarify/correct the ordering of API and Cell database schema updates

Everyone seems to agree that the only sane ordering of these operations
is "api first, cell after." However, grenade and our own documentation
shows the api database as coming after the main one. I believe this
was added to grenade in a sort of append operation, and thus after the
main database. This was done back when usage of the API database was
still optional (for upgrades) and thus the ordering didn't matter much.
Since the process has been correct (api first) in devstack for a long
time, and since grenade runs after devstack, we haven't had any issues.
A recent change to add something to a core data structure column format
highlighted the out-of-order-ness of this.

I also believe the docs got the same append behavior when adding the
command to the list, and/or it may have been copied from grenade, which
is our in-code manifestation of the upgrade steps.

Change-Id: I19f263ed314a8b01bbb07337467392cc1c146b66
Related-Bug: #1761775
This commit is contained in:
Dan Smith 2018-04-06 08:24:33 -07:00
parent 887dc23a17
commit 104c9e6375

View File

@ -70,7 +70,7 @@ same time.
including all the python dependencies.
* Using the newly installed nova code, run the DB sync.
(``nova-manage db sync``; ``nova-manage api_db sync``). These schema
(``nova-manage api_db sync``; ``nova-manage db sync``). These schema
change operations should have minimal or no effect on performance, and
should not cause any operations to fail.
@ -170,6 +170,15 @@ the routines that transform our database structure, which should be
additive and able to be applied to a running system before service
code has been upgraded.
.. note::
The API database migrations should be assumed to run before the
migrations for the main/cell databases. This is because the former
contains information about how to find and connect to the latter.
Some management commands that operate on multiple cells will attempt
to list and iterate over cell mapping records, which require a
functioning API database schema.
Data Migrations
'''''''''''''''''