Reorganize migrations after DB 'healing'
This specification proposes a solution for: - removing existing plugin-specific migrations - removing logic for creating plugin-specific migrations - squashing intra-release migrations for old releases Change-Id: Ieaa159f6c18a0cf682140da864cb33d772584ac0
This commit is contained in:
parent
2056b39c65
commit
baf44e425f
|
@ -0,0 +1,209 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
===========================================================
|
||||
Reorganize neutron migrations (Once they've been 'healed')
|
||||
===========================================================
|
||||
|
||||
https://blueprints.launchpad.net/neutron/+spec/reorganize-migrations
|
||||
|
||||
A good chunk of current migrations apply only to certain plugins making them
|
||||
configuration-dependent. A migration path dependent on configuration poses a
|
||||
serious upgrade problem. The Neutron DB is being restructured in a way that
|
||||
the DB schema will always be the same regardless of Neutron's configuration.
|
||||
For this reason, logic for handling configuration-dependent migrations should
|
||||
go; similarly configuration dependent migrations should be made 'independent'.
|
||||
Possibly they should also be squashed so that by reducing the overall number
|
||||
of migration we might be able to speed up DB ugrade process.
|
||||
|
||||
The work described in this blueprint relies on the Neutron DB healing
|
||||
blueprint, whose spec can be found at: https://review.openstack.org/95738/
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
There are currently over 100 migrations in Neutron's DB upgrade path.
|
||||
A migration often applies only to certain plugins, and is skipped if currently
|
||||
neutron is configured with a different plugin. This creates a serious upgrade
|
||||
problem.
|
||||
|
||||
As an example, the devstack job for Neutron for testing an upgrade from havana
|
||||
to icehouse fails because the 'metering' service plugin is specified only in
|
||||
the icehouse configuration; however since it was introduced in havana, some
|
||||
fundamental migrations to make it work where skipped. Hence the upgrade fails
|
||||
as soon as the first migration touching metering DB models is encountered.
|
||||
|
||||
This problem is already being dealt with by "healing" neutron DB schema in a
|
||||
way such that its end state will be the same regardless of conf values.
|
||||
|
||||
Nevertheless, there a few more things to take care of:
|
||||
|
||||
* Existing DB migrations which apply to specific plugins must become
|
||||
plugin-agnostic
|
||||
|
||||
* The logic for handling plugin-specific migrations should go in order to
|
||||
prevent plugin-specific migration from being pushed in the future.
|
||||
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
The proposed change is rather simple: remove the logic for skipping
|
||||
migrations according to the current configuration, and make all migrations
|
||||
"global".
|
||||
|
||||
As this blueprint looks back at the whole migration history, which stretches
|
||||
back to folsom, this is also a good chance to coalesce this rather long path
|
||||
by squashing intra-release migrations together, and removing from the path
|
||||
versions which are now not anymore supported.
|
||||
|
||||
For instance, the revised path could:
|
||||
1) Start at Havana Release
|
||||
|
||||
2) Have a single, configuration-independent, migration to Icehouse
|
||||
|
||||
3) Resume the 'traditional' path from Icehoue up to trunk, ensuring that
|
||||
all migrations in this path become however configuration-independent
|
||||
|
||||
This new migration path MUST ensure correct operation of upgrade/downgrades
|
||||
from Havana to Icehouse. To this aim, this change will introduce:
|
||||
|
||||
* A new 'Havana' initial state. This will be independent from configuration
|
||||
|
||||
* A single migration to go from Havana to Icehouse and vice versa.
|
||||
This migration will be able to upgrade an Havana database to Icehouse and
|
||||
viceversa. The downgrade side of this migration will assume the Icehouse
|
||||
schema is already in an "healed" state. Hence the following step.
|
||||
|
||||
* A healing step immediately before Icehouse. This migration will
|
||||
have only the downgrade side. This is for ensuring the database is in a
|
||||
healed state as the new downgrade migration to Havana makes this
|
||||
assumption. Being the healing migration idempotent, this should not
|
||||
be a problem.
|
||||
|
||||
NOTE: If there is consensus to keep allowing users running unsupported
|
||||
releases to upgrade to Icehouse directly then initial statuses for Folsom
|
||||
and Grizzly might be kept.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
One alternative would be to leave everything as it is at the moment, and add
|
||||
a test (integrated with flake8) to prevent new plugin-dependent migrations
|
||||
from being added to the path; Also the check for asessing whether a migration
|
||||
should be executed or skipped will be bypassed.
|
||||
|
||||
This should work, but it will still leave us with a lot of plugin-specific
|
||||
migrations which might confuse users. Also, there will be leftover, unused
|
||||
code in the source tree which will eventually end up bitrotting.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
The migration path up to Havana will be removed.
|
||||
This can be substituted with Grizzly if there is an agreement to provide
|
||||
users running the now unsupported Grizzly to uprade to a more recent release.
|
||||
|
||||
Intra-release migrations between Havana and Icehouse (and possibly between
|
||||
Grizzly and Havana) will be squashed into a single migration.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
Nada
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
Nonw
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
If migrations are squashed, upgrade will obviously be faster.
|
||||
No impact for runtime performance.
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
Operators which already already running havana should be able to upgrade
|
||||
to icehouse without any problem.
|
||||
|
||||
For operators running Icehouse, Havana downgrade should be smooth, both if
|
||||
they executed or not already the 'healing' migration.
|
||||
|
||||
Operators running versions prior to Havana might still be supported,
|
||||
if versions older than Havana are kept in the migration path.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
It will be no longer possible to create plugin-specific migrations.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
In rough terms we might expect a first step where the migration logic is
|
||||
removed, and all migrations made independent of configuration.
|
||||
In a second step instead a new initial state will be defined and intra-release
|
||||
migrations prior to Icehouse will be squashed.
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
salvatore-orlando
|
||||
akamyshnikova
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
Even if these work items are not orthogonal, dependencies among them are not
|
||||
necessarily represented by the order in which appear in this document.
|
||||
|
||||
* remove all folsom and grizzly migrations. Create a new "Havana" initial
|
||||
migration - in a "healed" state.
|
||||
* make conditional migrations unconditional
|
||||
* ensure a healing step is performed also in downgrade direction.
|
||||
This is for ensuring unconditional downgrades don't fail because of a
|
||||
database not in a "healed" state.
|
||||
* remove logic for managing conditional migrations
|
||||
* squash migration between havana and icehouse in a single migration
|
||||
* deal with conditional migrations between "icehouse" and the healing step
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
DB migration refactoring is a prerequisite for this blueprint.
|
||||
https://review.openstack.org/#/c/95738/
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
No additional tests should be added. Instead, some unit tests concerning
|
||||
plugin-specific migrations might be removed.
|
||||
|
||||
Existing grenade tests should be enough to validate the new upgrade path.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
None
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
None
|
Loading…
Reference in New Issue