Allow DB migration backports to Icehouse
Just as we did at the beginning of the Havana and Icehouse dev cycles, we need to reserve a range of DB migrations as the first DB change in Juno. This will allow a range to be used for migration backports to Icehouse if needed. This is a straight forward blueprint that has been implemented for the last two releases (Havana and Icehouse), so we can use this as a trial run for our new blueprint review process before we open up all other spec reviews. Since this is the first Juno spec, re-add the Juno specs directory to index.rst. Related to blueprint backportable-db-migrations-juno. Change-Id: I791c22b54ac8cd533d6fdc03ea93f12d4a907b23
This commit is contained in:
Russell Bryant
parent
037adec4b8
commit
039960e312
|
|
@ -18,8 +18,7 @@ Juno approved specs:
|
|||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
.. Uncomment this once a spec merges.
|
||||
specs/juno/*
|
||||
specs/juno/*
|
||||
|
||||
==================
|
||||
Indices and tables
|
||||
|
|
|
|||
|
|
@ -0,0 +1,135 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========================================
|
||||
Allow DB migration backports to Icehouse
|
||||
==========================================
|
||||
|
||||
https://blueprints.launchpad.net/nova/+spec/backportable-db-migrations-juno
|
||||
|
||||
Just as we did at the beginning of the Havana and Icehouse dev cycles, we need
|
||||
to reserve a range of DB migrations as the first DB change in Juno. This will
|
||||
allow a range to be used for migration backports to Icehouse if needed.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Normally, it is not possible to backport a change that requires a database
|
||||
migration due to the linear versioned nature of the migrations. For the last
|
||||
two releases (Havana and Icehouse), we have reserved a set of empty migrations
|
||||
as placeholders to allow for migration backports if needed.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
The proposed change is to reserve 10 migrations for Icehouse backports. These
|
||||
migrations would be no-ops and would simply result in an increment of the schema
|
||||
version.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
When figuring out ways to allow database migrations, alternatives usually
|
||||
involve discussion of drastic changes to the way we manage migrations. For
|
||||
example, it could require moving to a new framework. This proposal works for
|
||||
our current use of sqlalchemy-migrate. This will also be the third release
|
||||
we've used this approach, so it's fairly well understood at this point.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
There's no changes to the data model as a part of this effort. It simply gives
|
||||
us the ability to backport data model changes to Icehouse.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
These migrations have minimal cost and can be run against a database without
|
||||
taking down Nova services.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
This set of changes requires doing database migrations. However, they can be
|
||||
done without any Nova downtime.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
This must be the first set of migrations merged into Juno, or it doesn't work.
|
||||
|
||||
Developers must also be very careful when writing migrations that may be
|
||||
backported. They must be idempotent. For example, if migration 115 is
|
||||
backported to 107 in the previous release, someone who has executed the
|
||||
backported migration must not suffer any trouble when the migration runs again
|
||||
after an upgrade.
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
russellb
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Create 10 placeholder migrations.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
The existing unit tests will cover this. Both the normal devstack based CI
|
||||
systems, as well as the "turbo-hipster" DB CI system will provide functional
|
||||
test coverage of these placeholder migrations.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
None.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
* https://blueprints.launchpad.net/nova/+spec/backportable-db-migrations-icehouse
|
||||
|
||||
* https://blueprints.launchpad.net/nova/+spec/backportable-db-migrations
|
||||
|
||||
* http://lists.openstack.org/pipermail/openstack-dev/2013-March/006827.html
|
||||
Loading…
Reference in New Issue