This reverts commit f0be5f1a83.
We broke with this reverted patch db migration for stadium
projects like neutron-vpnaas, networking-bgpvpn,
networking-bagpipe and all others which have neutron
related db migration scripts from Liberty and older releases.
Change-Id: Ib77cdf6f7cb2e975581aeb2106690d35e798dc7c
This patch squashes the DB alchemy migration from Liberty
branch. The contract and expand migration steps are added
to the initial operation files. The unneeded tables or
parameters are not created.
Now the starting migration milestone is Mitaka.
Change-Id: Ia5bd25411149d1c475c142a60814c6daa8566cae
Fix E402 (module level import not at top of file) pep8 errors
and no longer ignore new failures.
Trivialfix
Change-Id: If9a202f1f322b5b03966c692e33e94b7c872079b
A problem was found with the --expand (and --contract) options, see the bug report. I am reverting this patch so that I can redo it and have one single patch that can be back-ported.
Closes-Bug: #1599574
This reverts commit 88359e3fe9.
Change-Id: Iebca469c6fec32bac0480be6627ad5e9dedaad9d
We plan to have all projects that integrate with Neutron use the same
alembic environment (Neutron's) instead of having a separate alembic
env.py in each repo. This means that each project will need to label
their contract and expand branches uniquely.
With this patch we add support for branch labels of the form
'networking-foo-contract'
'networking-foo-expand'
We also support the old labels ('contract' and 'expand') with the
intent of backporting this patch to Mitaka so that projects can be
backwards compatible when they update their alembic branch labels. A
best effort will be made to backport this patch to Liberty also.
Support has been removed for label names starting with a "liberty_"
prefix. Such labels temporarily existed during the Liberty cycle but
have now all been cleaned up.
Partial-Bug: #1497830
Change-Id: Ibf38b3125d5d404d57f3e8ef0c7ecfa56eaf8042
Since the plan is to attach first Mitaka scripts to Liberty branches
with down_revision, and since labels are inherited from all other
revisions in the chain, using release names in branch labels would mean
that the following commands would be valid:
neutron-db-manage upgrade liberty_expand@<some_revision_from_mitaka>
neutron-db-manage upgrade mitaka_expand@<some_revision_from_liberty>
which may be confusing to users.
So let's drop release names from branch labels and use expand@head and
contract@head to access latest migrations.
Change-Id: Id524d7673ad248c831f6dbb3a6f2f3c50094acae
Partially-Implements: blueprint online-schema-migrations
alembic.get_heads() returns all heads for all branches it can find in
scripts dir, while in alembic_version table, it does not store any heads
that were overridden by other branches, even if those depends_on it
instead of having it as down_revision.
To keep 'current' output in sync with what is in HEADS file, we can
attach liberty_* branches explicitly to kilo revision.
It's also a good idea to have a separate 'heads' command that would show
the latest alembic heads based on scripts dir state. See [1] for more
details.
While at it, since different subprojects can link their expand/contract
branches to kilo in different way (some using depends_on the previous
release branch, while others, as suggested in this patch, thru
down_revision to kilo), we kill the check on the number of heads
returned by script.get_heads() since it may differ. If we want to
validate that we don't branch more than twice from kilo, we may add a
separate validation just for that.
[1]: https://review.openstack.org/#/c/204551/
Change-Id: If551633ab26e0eac549c1e13cfa0771383a1a060
Partially-Implements: blueprint online-schema-migrations
New migration rule scheme is introduced. Now, changes are classified
into the following branches:
- expand (additive changes only)
- contract (contraction changes, including data migration)
Make 'neutron-db-manage revision' generate two separate migration
scripts, one per branch.
Now that we support multiple heads, renamed HEAD file in HEADS. We still
don't allow more branching, so keep validation for the number of
branches.
For backwards compatibility, calling to 'upgrade head' applies both
branches in proper order.
Note that advanced services will be moved to the new migration scheme in
separate patches for respective repos.
This patch does not introduce autogenerate support for multiple branches
for 'revision' command (that depends on a new alembic version yet
unreleased; but alembic/master already has everything to support us).
The patch does not implement 'expand' or 'contract' commands that are
anticipated by the spec proposal. Those will come in consequent patches.
Upgrade impact is backwards compatible: those who are interested in
reducing downtime while applying some migration rules can opt in it by
modifying their upgrade practices, while everything should still work
the old way for those who don't care.
blueprint online-schema-migrations
DocImpact
UpgradeImpact
Change-Id: I3823900bc5aaf7757c37edb804027cf4d9c757ab
Slawek Kaplonski