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
It has long been *recommended* that the placement service be upgraded
before nova services, but scenarios where it isn't have never really
been explored or tested. Following (yet another) discussion on the
topic [1] it was decided that we are best served by *requiring* that
placement be updated first. This simplifies our test/support matrix,
and the code we write to consume placement. It also makes the operator
experience cleaner by giving them a clear and unambiguous script to
follow.
This change set rewords the upgrade document accordingly.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-03-26.log.html#t2018-03-26T17:35:11
Change-Id: I97215e94efdd8c05045872fb9ba7d2089dc6efb8
This adds a mention of the nova-scheduler service requiring
placement 1.17 and also links to the placement upgrade notes
from the more general upgrade notes, since we are now firmly
in a place where placement needs to be upgraded before nova.
Since we consider placement global, this removes the 1.14
note about nova-compute since we assume that if you're going
to upgrade placement to get 1.17 for the scheduler, and control
services should be upgraded before computes, then the computes
are going to get a new enough placement service automatically.
Change-Id: I06937c7642dca4a1932cbbf46569acc9c58e44a6
There is no --limit option on the online_data_migrations
command, it's called --max-count.
This fixes that typo in the upgrades doc and also fixes
another grammar nit that was bugging me.
Change-Id: Ib76ced58314e025f617c1b4d964cd0c62d908a37
Related-Bug: #1670738
Per the spec [1]:
user/ – end-user content such as concept guides, advice, tutorials,
step-by-step instructions for using the CLI to perform specific tasks,
etc.
The remaining content all ends up in here.
[1] specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration
Change-Id: I480eee9cd7568efe2f76dd185004774588eb4a99
Dan Smith