104c9e6375
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 |
||
---|---|---|
.. | ||
aggregates.rst | ||
architecture.rst | ||
block-device-mapping.rst | ||
cells.rst | ||
cellsv2-layout.rst | ||
conductor.rst | ||
config-drive.rst | ||
feature-classification.rst | ||
feature-matrix-gp.ini | ||
feature-matrix-hpc.ini | ||
feature-matrix-nfv.ini | ||
filter-scheduler.rst | ||
flavors.rst | ||
index.rst | ||
launch-instance-from-image.rst | ||
launch-instance-from-volume.rst | ||
launch-instance-using-ISO-image.rst | ||
launch-instances.rst | ||
manage-ip-addresses.rst | ||
metadata-service.rst | ||
placement.rst | ||
quotas.rst | ||
support-matrix.ini | ||
support-matrix.rst | ||
upgrade.rst | ||
user-data.rst | ||
vendordata.rst | ||
wsgi.rst |