yahoo-eng-team team mailing list archive

[Morgan Fainberg <morgan@xxxxxxxxxxxxx>]

Public bug reported:

The code in openstack.common.db.sqlachemy.migration that does the sanity
checking on the UTF8 table is a bit overzealous and checks the
migration_version (and alembic equivalent) table for utf8 status. This
will cause migrations to fail in any case where the db isn't forcing a
default character set of utf8, the db engine isn't forced to utf8, or
the migration_version table isn't fixed before migrations occur.

This was duplicated by doing a clean Ubuntu 12.04 install with mysql,
using the default latin1 character set and simply creating the DB with
``create database keystone;``

The result is migrations fail at migration 0 unless the db sanity check
is disabled (e.g. glance).

root@precise64:~/keystone# keystone-manage --config-file /etc/keystone.conf db_sync
2014-04-01 14:03:23.858 19840 CRITICAL keystone [-] ValueError: Tables "migrate_version" have non utf8 collation, please make sure all tables are CHARSET=utf8

This is unaffected by the character set in the connection string.

The solution is to explicitly ignore the migrate_version (and alembic
equivalent) table in the sanity check.

Code in question is here:

http://git.openstack.org/cgit/openstack/keystone/tree/keystone/openstack/common/db/sqlalchemy/migration.py?id=51772e1addf8ab6f7483df44b7243fd7842eba4a#n200

This will affect any project using this code for migrations when using
the mysql engine.

** Affects: ironic
     Importance: Undecided
         Status: Invalid

** Affects: keystone
     Importance: Undecided
         Status: New

** Affects: oslo
     Importance: Undecided
         Status: New


** Tags: icehouse-rc-potential

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

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

** Description changed:

  The code in openstack.common.db.sqlachemy.migration that does the sanity
  checking on the UTF8 table is a bit overzealous and checks the
  migration_version (and alembic equivalent) table for utf8 status. This
  will cause migrations to fail in any case where the db isn't forcing a
  default character set of utf8, the db engine isn't forced to utf8, or
  the migration_version table isn't fixed before migrations occur.
  
  This was duplicated by doing a clean Ubuntu 12.04 install with mysql,
  using the default latin1 character set and simply creating the DB with
  ``create database keystone;``
  
  The result is migrations fail at migration 0 unless the db sanity check
  is disabled (e.g. glance).
  
  root@precise64:~/keystone# keystone-manage --config-file /etc/keystone.conf db_sync
  2014-04-01 14:03:23.858 19840 CRITICAL keystone [-] ValueError: Tables "migrate_version" have non utf8 collation, please make sure all tables are CHARSET=utf8
  
  This is unaffected by the character set in the connection string.
  
  The solution is to explicitly ignore the migrate_version (and alembic
  equivalent) table in the sanity check.
  
  Code in question is here:
  
  http://git.openstack.org/cgit/openstack/keystone/tree/keystone/openstack/common/db/sqlalchemy/migration.py?id=51772e1addf8ab6f7483df44b7243fd7842eba4a#n200
  
- This will affect any project using this code for migrations.
+ This will affect any project using this code for migrations when using
+ the mysql engine.

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1301036

Title:
  openstack.common.db.sqlalchemy.migration utf8 table check issue on
  initial migration

Status in Ironic (Bare Metal Provisioning):
  Invalid
Status in OpenStack Identity (Keystone):
  New
Status in Oslo - a Library of Common OpenStack Code:
  New

Bug description:
  The code in openstack.common.db.sqlachemy.migration that does the
  sanity checking on the UTF8 table is a bit overzealous and checks the
  migration_version (and alembic equivalent) table for utf8 status. This
  will cause migrations to fail in any case where the db isn't forcing a
  default character set of utf8, the db engine isn't forced to utf8, or
  the migration_version table isn't fixed before migrations occur.

  This was duplicated by doing a clean Ubuntu 12.04 install with mysql,
  using the default latin1 character set and simply creating the DB with
  ``create database keystone;``

  The result is migrations fail at migration 0 unless the db sanity
  check is disabled (e.g. glance).

  root@precise64:~/keystone# keystone-manage --config-file /etc/keystone.conf db_sync
  2014-04-01 14:03:23.858 19840 CRITICAL keystone [-] ValueError: Tables "migrate_version" have non utf8 collation, please make sure all tables are CHARSET=utf8

  This is unaffected by the character set in the connection string.

  The solution is to explicitly ignore the migrate_version (and alembic
  equivalent) table in the sanity check.

  Code in question is here:

  http://git.openstack.org/cgit/openstack/keystone/tree/keystone/openstack/common/db/sqlalchemy/migration.py?id=51772e1addf8ab6f7483df44b7243fd7842eba4a#n200

  This will affect any project using this code for migrations when using
  the mysql engine.

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