This removes db2 support from tree completely. This is an oddball non
open database that made doing live data migrations difficult. It is
used by 0% of users in the OpenStack User Survey.
Supporting commercial software that doesn't have users at the cost of
delivering features and fixes to our community is the wrong
tradeoff. This corrects that.
It rewrites migrations, which we typically don't ever do, but it is
better if newton fresh environments fail early in db creation instead
of very deep in the data migration process.
Change-Id: Ifeb9929e4515e3483eb65d371126afd7672b92a4
Misspelling in the message:
"You have uncommited changes"
Should be: "You have uncommitted changes"
Totally 2 occasions in Nova base code.
Change-Id: If0ad3163f3b9db3f31f7e9fa40245282c1a0acb4
Notes on migration changes/tests:
1. The initial havana migration does not create any foreign keys which
require the instances.uuid column since it's nullable and DB2 won't
allow creating a unique constraint over a nullable column. To create
the foreign keys on instances.uuid, this change depends on commit
e07a2b2d4be0503ad8dad75daa632be27cf83320 to make instances.uuid
non-nullable and create a unique constraint on that column. Then
the new migration here creates the missing instances.uuid
related foreign keys for DB2.
2. Commit b930fb3a6b0ab8cbe0c19eb3ab8ba33d60d147be changed
test_migrations.py to use oslo.db's opportunistic test fixture
which currently only supports sqlite/mysql/postgresql. Unit test
support for DB2 therefore needs to be added to oslo.db and then
hooked into nova, but that's targeted for the 2016.1 'M' release
so is not part of this change.
3. The 247_nullable_mismatch migration is updated for DB2 because
making the pci_devices.deleted column nullable=True fails since
the column is in a UniqueConstraint already (DB2 would require
it to be in a unique index instead for the column to be nullable).
There is a foreign key involved (created in 246) so for DB2 to
have the same FKey it requires a UC and that requires the deleted
column to be non-null, which doesn't work with the SoftDeleteMixin.
So in this case the schema will diverge for DB2 until we make
the deleted column non-nullable for all tables.
4. The 252_add_instance_extra_table migration is updated for DB2
because a foreign key is created between the instance_extra
table and the instances.uuid column (which is nullable at the
time) so we have to handle that foreign key constraint creation
in the 296 migration with the other foreign keys to
instances.uuid.
5. The 271 migration is updated to add ibm_db_sa the same as
sqlite and postgresql since it works the same in this case for
DB2.
6. The API migrations need checks for DB2 to avoid a duplicate index
SQL0605W error since DB2 implicitly creates an Index when a
UniqueConstraint is created and will fail if trying to add a
duplicate index on the same column(s) that are in the UC.
Implements blueprint db2-database
Change-Id: Ic4224e2545bcdfeb236b071642f9f16d9ee3b99f
As discussed in the Liberty Design Summit "Moving apps to Python 3"
cross-project workshop, the way forward in the near future is to
switch to the pure-python PyMySQL library as a default.
https://etherpad.openstack.org/p/liberty-cross-project-python3
Change-Id: I590c26523f4dc8d14c45e61bb89555486629b64d
This patch fixes the pep8 issues of the tool scripts and
configures tox to run pep8 on the tools directory.
Two hacking rules have been modified to ignore the tool directory as both
rules are checking oslo usage which is not critical in case of tools
- N310 use timeutils instead of datetime module
- N324 use jsonutils instead of json module
The tools/xenserver directory is still excluded from pep8 as it contains
scripts that are expected to run on dom0 with python2.4 therefore the
following rules cannot be meaningfully followed
- H231 Python 3.x incompatible 'except x,y:' construct
- H233 Python 3.x incompatible use of print operator
Change-Id: Icfd9e708a2ca1e421676b410e41807b2e630718f
oslo.i18n provides the i18n functions that were provided by
oslo-incubator's gettextutils module. Some tests that were
using internal details of the library were removed.
Change-Id: I44cfd5552e0dd86af21073419d31622f5fdb28e0
We don't need to have the vi modelines in each source file,
it can be set in a user's vimrc if required.
Also a check is added to hacking to detect if they are re-added.
Change-Id: I347307a5145b2760c69085b6ca850d6a9137ffc6
Closes-Bug: #1229324
The exising schema_diff code had the DB URL format hard-coded which made it
difficult to work with since different environments with have different
user/password configurations.
A more flexible way to handle this, is to have the DB URL specified directly
on the command-line.
Change-Id: I313bb616e439072e007c886a7f131efc6a61f6df
This gets rid of a SQLAlchemy deprecation warning when using this tool w/
PostgreSQL:
The SQLAlchemy PostgreSQL dialect has been renamed from 'postgres' to
'postgresql'. The new URL format is
postgresql[+driver]://<user>:<pass>@<host>/<dbname>
This appears to have been deprecated in the SQLAlchemy 0.6 series so I think we
are Okay to remove it now.
Change-Id: If8fdf822ba452b387e9f2f3ec7c9157e4ae932f9
This is for Python 3 compatibility, since Python 3 does not support
the print statement, only the print function. (Python 2.6 and 2.7
support both, depending on whether a __future__ import is used.)
Paths containing "xen" were left alone, because of comments in a
couple of the files indicating that the XenServer code needed to be
compatible with Python 2.4.
Fixes bug 1226943
Change-Id: I23b804a4d99500b4acf81dd19645ab06dfcc9f1c
Previous _ was monkey patched into builtins whenever
certain modules were imported. This removes that and
simply imports it when it is needed.
Change-Id: I0af2c6d8a230e94440d655d13cab9107ac20d13c
Provide i18n to some exceptions that were not
provided before.
Change-Id: Ia320ba5f12e82686c8ee7973a77f152eb4b02bd4
Signed-off-by: Chuck Short <chuck.short@canonical.com>
This patch removes some assumptions from the tool and turns it in to a
generalized schema diffing tool where any two versions of the DB schema,
represented by branch-version pairs, can be diffed.
To reflect the more genernal nature, the name was changed to
schema_diff.py.
Change-Id: I4dc233fa2d4b084779922893f76baa753fe2c126
This tool can be used to diff the schemas pre and post migration to
validate that nothing fundamental has changed during the compaction
process.
Change-Id: I178c849aa93467898a7c9bf1d2128d28af1b1ad4