Since SQLAlchemy 1.4, the method "Inspector.from_engine()" is
deprecated.
Error message:
"The from_engine() method on Inspector is deprecated and will be removed
in a future release. Please use the sqlalchemy.inspect() function on an
Engine or Connection in order to acquire an Inspector. (deprecated
since: 1.4)"
Minimum version of SQLAlchemy required is bumped to 1.4.23.
Change-Id: I6cf5944ccb3a0532cbf123ddc0d7df6b6de80af1
Closes-Bug: #1943155
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
At this moment setting server_default can be lost with using
alter_enum(_add_value) function. This change make it possible to pass
existing server_default for the column.
Change-Id: I187d62aa5fa67487b9f01ebb691d66a318288280
This helps catch a number of potential issues with the neutron
code in advance. A false positive can be skipped with #nosec
at the offending line, just like #noqa can be added on
offending module imports.
Change-Id: I3e4cbc94539dd2cce61bfa5cd0265e75d7336311
Before walking through migration scripts that belong to the release
under development, we should first execute all scripts for the latest
official release because it serves a convergence point. Without it, we
can't guarantee that calling --expand will succeed because some of new
scripts may depend on schema state that is defined by contract scripts.
Change-Id: I501b38900fb2f4409839ecd09be4d937cf20c6a9
Related-Bug: #1671634
Using alter_enum_add_value for PostgreSQL hit error with running
inside migration.
Update code with operations that can be executed. As this implementation
do not drop columns like alter_enum, it can be used in expand branch
as well.
Change-Id: I56d0731fff317b7be73e8237fa897c1d44331bcd
'%' (value) s in the execution SQL statement of alter_enum_add_value
should be decorated with ' '
Ralated commit I4767222ba97d9c35c011adfc187b2977975f981a
Change-Id: I24138e5b4ec8b3c3126ae5ff79e26ecb91a65d69
PostgreSQL is more sensible with Enums, than MySQL. We have special
function alter_enum to deal with updated Enums.
PostgreSQL ALTER TYPE is expanded now [1], so this change introduce
function for adding new values in Enums that are already created.
[1] - https://www.postgresql.org/docs/9.1/static/sql-altertype.html
Change-Id: I4767222ba97d9c35c011adfc187b2977975f981a
We hit a problem that Neutron migrations cannot be applied
on galera cluster with ENFORCING mode as alembic_version table
missing primary key on the table and it is expected that all tables
will have primary keys.
alembic_version is created and managed by Alembic and fixes for this
on Alembic side are on the review [1]. Anyway here migration is
proposed that will add pk on this table if it is missing, as in
other case we will have inconsistency between new deployments and
old ones.
[1] - https://gerrit.sqlalchemy.org/#/c/279/
Change-Id: I543a1ee286bdf11ae35adb87125d044a351a2648
Closes-bug: #1655610
Function used in alembic database migration script to
remove foreign keys from table doesn't remove unique constraint
created for such fk in table.
Sometimes there is need to remove also such unique constraint during
database upgrade.
Removing unique constraint is little bit different in mysql and
postgresql databases because names of such constraints are different.
This patch introduces function to remove constraints from table
during migration.
It is also used in remove_fks_from_table() function to allow removal
unique constraints when fk is removed.
Change-Id: I7e7732560984b1c1e45230434ddc4be8cf5ab630
Closes-Bug: #1599840
Columns are added/dropped by alembic clauses in migrations, and
checking for them differs from how sqlalchemy clauses are checked.
Closes-Bug: #1589328
Change-Id: Ia0f39697afddec7cd04f870746a4bdd8b9410a32
When postgresql is used as the backend and alter_enum is called.
The old type of enum will be dropped. But there is a case which
the old type is used by more than one column, in different table
eg. Then the drop operation will be failed. Add do_drop,do_rename,
do_create to let developer to decide whether these operations should
be skipped or not.
Change-Id: I708288e2cc507017d9f6512b567e3bfc77dfd761
Closes-Bug: #1568436
The create_foreign_keys method there forces any foreign keys that
created to have ondelete='CASCADE', no matter whether the
foreign_keys parameter passed to the method had that option set.
if the wrapper method remove_fks_from_table() is used to preserve
the state of foreign keys during a database migration, any foreign
keys on the table "perserved" this way will have cascading delete
added to them.
Change-Id: I04bdc863d67e2228f34a05f588c2e9f562918114
Closes-Bug: #1550027
Also, don't initialize a new 'per-release' directory with new revisions
that have branch labels because we don't maintain per release labels
anymore.
Change-Id: I3a875e239602147d82d28994788c3409d64d6992
Previously when we had one repo with one alembic branch we would
create a milestone revision on that single branch. Now we have
multiple repos and expand/contract branches for each repo.
So from now on we tag the final revision on every branch when we make
a milestone release. Update the cli to support the command:
neutron-db-manage upgrade <milestone>
where <milestone> becomes an alias for all the revisions for a
milestone.
Partial-Bug: #1499033
Change-Id: I38623986dd574bec01fe147f9c6a747f3f512bb7
Adding a constraint to a table shouldn't be restricted
to an expand operation. There can be contraction migrations
required before the constraint can be safely added (e.g. inserting
records into the target table of the constraint).
Change-Id: I1963facaa6ab1916d92c044f90b6c00291f00ab9
This test will check that expand branch does not contain drop SQLAlchemy
operations and contract branch does not contain create/add SQLAlchemy
operations.
Partially-Implements: blueprint online-schema-migrations
Change-Id: Ifda31c0599651931c1a98f673f3b10e64538f18b
Related-bug: #1490767
Version 0.8.0 of alembic has renamed some arguments in some of its
methods. This generates warnings when running neutron's alembic
migration scripts.
Change-Id: I4f90a66c2465dd1d7f6631f297146754fd5e9cc4
Since MySQL 5.6 FK columns cannot be altered. As a workaround we can
drop the FK before ALTER COLUMN and then recreate it.
Change-Id: Icd1b3075cf29a6b0c477a4ddea2e6ebee91baef8
Closes-Bug: 1384555
We have git to track authorship, so let's not pad source files
with it as well.
A hacking check has been added for this. The value is N322.
Change-Id: Iab0b64d417e0bb41a6b455e2ac377deee64ec3ee
This patch removes the logic for handling conditional migrations
and adjusts all the patches where it was used accordingly.
The alembic environment has been update to not send anymore
the active plugins list to migrations.
This patch also removes the vestigial 'options' parameter which
was sent to every migration but always set to None and never
used by any migration.
Implements blueprint bp/reorganize-migrations
Change-Id: I7285e0276b262a9ea5d22c456a5a8cf34c461a0c
This patch amends migrations added after the icehouse release
and before the healing migration.
Migrations are changed in a way that they are not anymore
dependent on configuration parameters but are anyway aware of
the fact that the database has not yet been healed.
To this aim, amended migrations now will need to inspect the
current schema and cannot be anymore be used in offline mode;
this is consistent with the behaviour of the healing migration.
This patch does not remove the logic for generating and
managing configuration-dependent migrations. For this reason
upgrade and downgrade routines still accept the active_plugins
parameter, which will not be used.
Change-Id: I9d55a01c64ef555b7774099f497c9eea596aea6e
Partially-implements: blueprint reorganize-migrations
If PostgreSQL version is less than 9.1.13 migration
set_length_of_description_field_metering fails as there is no
special 'create if not exist' expression. This change add special
function for this case.
Closes-bug: #1348138
Change-Id: Ibe4f370fe400072abd281bd2313261790335eae2
In migration 1341ed32cc1e_nvp_netbinding_update Enum type had been
changed incorrectly from ('flat', 'vlan', 'stt', 'gre')
to ('flat', 'vlan', 'stt', 'gre', 'l3_ext') for PostgeSQL.
The same problem is taken place for vlan_type in migrations
38fc1f6789f8_cisco_n1kv_overlay from ('vlan', 'vxlan', 'trunk',
'multi-segment') to ('vlan', 'overlay', 'trunk', 'multi-segment')
and in 46a0efbd8f0_cisco_n1kv_multisegm from ('vlan', 'vxlan') to
('vlan', 'vxlan', 'trunk', 'multi-segment').
In this change request was added separate method for changing Enum
type for PostgreSQL.
Closes-bug: #1301396
Change-Id: I27197fb7405630a55178be8516a4b62bd135e05c
Currently we have many migration files with missing cisco
plugin in migrate_plugin when ovs is included.This
causes missing tables when cisco plugin is enabled
and migration is run. This fix should automatically
include the cisco plugin if ovs is detected in the
migrate_plugins.
Change-Id: I4dedfbafe9b431e85255d5427766e22eed09ee5e
Closes-Bug: #1292114
This commit also empties __init__.py and removes vim
modelines in the db migration related codes.
Change-Id: I9f83109c5becb6cf7e2e6ad9ad8eb9af3d8e0972
Closes-Bug: #1286991