Bug 1010039 - Grizzly -> Havana upgrade fails during db_sync
Grizzly -> Havana upgrade fails during db_sync
Product: RDO
Classification: Community
Component: openstack-cinder (Show other bugs)
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Eric Harney
Giulio Fidente
Depends On:
Blocks: 960990
  Show dependency treegraph
Reported: 2013-09-19 14:44 EDT by Dan Smith
Modified: 2016-04-26 17:55 EDT (History)
2 users (show)

See Also:
Fixed In Version: openstack-cinder-2013.2-0.13.rc3.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-05-14 10:18:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1233861 None None None Never
OpenStack gerrit 51917 None None None Never

  None (edit)
Description Dan Smith 2013-09-19 14:44:44 EDT
Description of problem:

Upgrading from Grizzly to Havana fails when trying to run cinder's database migrations.

Version-Release number of selected component (if applicable):

Starting with: 2013.1.3-1.el6
Upgrading to:  2013.2.0.8.b3.el6

How reproducible:


Steps to Reproduce:
1. Install 2013.1.3-1
2. Start cinder
3. Stop cinder
4. Install 2013.2.0.8.b3
4. Run "cinder-manage db sync"

Actual results:

[root@test1 test_rdo_upgrade(keystone_admin)]# cinder-manage db sync
2013-09-19 11:41:56.954 556 ERROR 010_add_transfers_table [-] Table |Table('transfers', MetaData(bind=Engine(mysql://cinder:7f6a941a6b2348a2@, Column('created_at', DateTime(), table=<transfers>), Column('updated_at', DateTime(), table=<transfers>), Column('deleted_at', DateTime(), table=<transfers>), Column('deleted', Boolean(), table=<transfers>), Column('id', String(length=36), table=<transfers>, primary_key=True, nullable=False), Column('volume_id', String(length=36), ForeignKey('volumes.id'), table=<transfers>, nullable=False), Column('display_name', String(length=255), table=<transfers>), Column('salt', String(length=255), table=<transfers>), Column('crypt_hash', String(length=255), table=<transfers>), Column('expires_at', DateTime(), table=<transfers>), schema=None)| not created!
2013-09-19 11:41:56.955 556 CRITICAL cinder [-] (OperationalError) (1005, "Can't create table 'cinder.transfers' (errno: 150)") '\nCREATE TABLE transfers (\n\tcreated_at DATETIME, \n\tupdated_at DATETIME, \n\tdeleted_at DATETIME, \n\tdeleted BOOL, \n\tid VARCHAR(36) NOT NULL, \n\tvolume_id VARCHAR(36) NOT NULL, \n\tdisplay_name VARCHAR(255), \n\tsalt VARCHAR(255), \n\tcrypt_hash VARCHAR(255), \n\texpires_at DATETIME, \n\tPRIMARY KEY (id), \n\tCHECK (deleted IN (0, 1)), \n\tFOREIGN KEY(volume_id) REFERENCES volumes (id)\n)ENGINE=InnoDB\n\n' ()

Expected results:

cinder-manage upgrades database schema properly.

Additional info:

Reproducible starting from a clean EL6 system with:

Comment 1 Dan Smith 2013-09-20 17:04:22 EDT
For easier copying, here's the failing SQL statement:

CREATE TABLE transfers ( created_at DATETIME,  updated_at DATETIME,  deleted_at DATETIME,  deleted BOOL,  id VARCHAR(36) NOT NULL,  volume_id VARCHAR(36) NOT NULL,  display_name VARCHAR(255),  salt VARCHAR(255),  crypt_hash VARCHAR(255),  expires_at DATETIME,  PRIMARY KEY (id),  CHECK (deleted IN (0, 1)),  FOREIGN KEY(volume_id) REFERENCES volumes (id) )ENGINE=InnoDB;

I think it must have something to do with constraints required for the Foreign Key relationship that aren't happy, but I'm not sure exactly.
Comment 2 Eric Harney 2013-10-02 15:57:28 EDT
Possible explanation: https://bugs.launchpad.net/cinder/+bug/1233861
Comment 3 Rich Bowen 2015-05-14 10:18:12 EDT
Refers to EOL'ed versions that are no longer maintained.

Note You need to log in before you can comment on or make changes to this bug.