yahoo-eng-team team mailing list archive

[Victor Sergeyev <vsergeyev@xxxxxxxxxxxx>]

We have a similar code in Oslo-incubator, so we should fix it there as
well

** Also affects: oslo
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1252693

Title:
  Running of unit tests fails if SQLAlchemy >= 0.8.3 is used

Status in OpenStack Compute (Nova):
  In Progress
Status in Oslo - a Library of Common OpenStack Code:
  New

Bug description:
  If SQLAlchemy >= 0.8.3 is used, running of unit tests fails. The
  following error is printed to stderr multiple times:

  DBError: (IntegrityError) constraint failed u'UPDATE
  instance_system_metadata SET   updated_at=?, deleted_at=?, deleted=?
  WHERE instance_system_metadata.id = ?' ('2013-  11-19
  10:37:44.378444', '2013-11-19 10:37:44.377819', 11, 11)

  A few of our migrations change the type of deleted column from boolean
  to int. MySQL and SQLite don't have native boolean data type.
  SQLAlchemy uses int columns (e.g. in case of MySQL - tinyint) + CHECK
  constraint (something like CHECK (deleted in (0, 1))) to emulate
  boolean data type.

  In our migrations when the type of column `deleted` is changed from
  boolean to int, the corresponding CHECK constraint is dropped too. But
  starting from SQLAlchemy version 0.8.3, those CHECK constraints aren't
  dropped anymore. So despite the fact that column deleted is of type
  int now, we still restrict its values to be either 0 or 1.

  Migrations changing the data type of deleted columns rely on SQL
  rendered for CHECK constraints (e.g.
  https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/migrate_repo/versions/152_change_type_of_deleted_column.py#L172).
  There was a patch in SQLAlchemy 0.8.3 release that slightly changed
  the way DDL statements are rendered
  ((http://docs.sqlalchemy.org/en/latest/changelog/changelog_08.html
  #change-487183f04e6da9aa27d8817bca9906d1)). Unfortunately, due to the
  fact that nova migrations depend on such implementation details, this
  change to SQLAlchemy broke our code.

  We must fix our migrations to work properly with new SQLAlchemy
  versions too (0.8.3+).

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1252693/+subscriptions