On 5/14/15 11:40 AM, Mike Bayer wrote:
Assuming I can get that done in the next few months, the next step
would be that the migration streams can be broken into branches, e.g.
juno, kilo, liberty, etc. so that we can easily add new migration
files that are backportable in place to a target backport.
Additionally, the issue of end-user migrations that are divergent from
what is part of Nova itself should also be achieved using additional
branches; if a customer wants to make their own changes to a database,
such as adding extra indexes, this can be done in their own
user-specific branch that will integrate with the primary migration
stream. That would eliminate the need for a system that is tasked
with diffing live database schemas and then executing decisions
directly without any chance to review or version-control the changes
that are being made.
I would also note that this system can maintain the "expand" and
"contract" idea from the online schema changes system, such that the
migration files themselves would be organized into branches for "expand"
and "contract" that can be run separately (the current Alembic branching
model did not exist at the time that the online schema changes spec was
written). This way the ability to run just the "expansion" in one
phase and the "contract" in another can be maintained; it's just the
migration steps themselves would live in version-controlled migration
files as they always do.
Does that help?
Thanks,
John
__________________________________________________________________________
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
__________________________________________________________________________
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
