Hi, I wrote up a POC implementing an example online schema migration in one release cycle: https://review.openstack.org/269693
This bases on the Online Schema Migration blueprint [1] and adds a configuration option to denote which columns are being used at a given time. The upgrade scenario for a rolling upgrade is the following: 1. Take one node out from the cluster, so that new HTTP API requests are managed by other nodes 2. Shut the service down on that node 3. Upgrade keystone application 4. Upgrade the DB schema with keystone-manage db_sync - only new columns are added at this point [note that some DDL statements may still lock tables] 5. Start the service and join it with the cluster 6. Do the above for the rest of the nodes 7. Once only the new version is running, the rest of the data can be migrated by normally operating the cluster or by running migration scripts with keystone-manage db_migrate (not yet implemented) 8. After data is migrated in full, the sql.backward_compatible configuration flag can be set to False and the services restarted (after this point, downgrade is not possible) 9. Run the "contract" scripts (I provided a working example script for this POC, which also migrates the remaining data) [again, note that some DDL statements may still lock tables, the operator should be aware of this] I think this can be a good moment for discussion on where online schema upgrades should go in the future and if this one release cycle upgrade which I'm proposing is a good approach. [1] https://blueprints.launchpad.net/keystone/+spec/online-schema-migration I also proposed additional documentation with guidelines at https://review.openstack.org/#/c/265252/ / Greg
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
