Bug 816424 - ERROR 1146 (42S02) at line 1: Table 'nova.migrate_version' doesn't exist
ERROR 1146 (42S02) at line 1: Table 'nova.migrate_version' doesn't exist
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openstack-nova (Show other bugs)
17
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Mark McLoughlin
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-25 23:13 EDT by Tommy P
Modified: 2014-01-25 05:47 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-06 09:51:42 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Tommy P 2012-04-25 23:13:33 EDT
Description of problem:
I'm trying to install OpenStack via Getting started in wiki.  I've setup the MySQL server, database, user with proper permissions on another system.  After making the necessary changes of connection string in the /etc/nova/nova.conf, I run openstack-nova-db-setup and got this error.

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

How reproducible:
100%

Steps to Reproduce:
1. Install MySQL server on another system.
2. Create database and user with all privileges to that database.
3. Install all OpenStack packages per Getting Started with OpenStack wiki.
4. Run 'openstack-nova-db-setup -n openstackPasswd -r rootPasswd.

Actual results:

[root@v-fedora17-d nova]# openstack-nova-db-setup -n openstackPasswd
Please enter the password for the 'root' MySQL user:
Verified connectivity to MySQL.
Creating 'nova' database.
ERROR 1396 (HY000) at line 2: Operation CREATE USER failed for 'nova'@'localhost'
Updating 'nova' database password in /etc/nova/nova.conf
Asking openstack-nova to sync the database.
ERROR 1146 (42S02) at line 1: Table 'nova.migrate_version' doesn't exist
Final sanity check failed.  File a bug report on bugzilla.redhat.com against the openstack-nova package.

Expected results:


Additional info:  Looking at the script openstack-nova-db-setup, looks like the 'nova-manage db sync' doesn't create the table nova.migrate_version.
Comment 1 Pádraig Brady 2012-04-26 05:47:57 EDT
If I understand correctly, you ran openstack-nova-db-setup on a,
different host than where your database was?

If that's the case, then it's not designed for that at present.
In that case the only significant part of the script is:

  nova-manage db sync

That doesn't seem to have generated an error, so could
you check if the nova.migrate_version table is actually present in your DB?

Now this report is still valid in that the script should
at least notice the separate DB host in /etc/nova/nova.conf,
and warn or handle directly.
Comment 2 Tommy P 2012-04-26 10:13:57 EDT
(In reply to comment #1)
> If I understand correctly, you ran openstack-nova-db-setup on a,
> different host than where your database was?
> 
> If that's the case, then it's not designed for that at present.
> In that case the only significant part of the script is:
> 
>   nova-manage db sync
> 
> That doesn't seem to have generated an error, so could
> you check if the nova.migrate_version table is actually present in your DB?
> 
> Now this report is still valid in that the script should
> at least notice the separate DB host in /etc/nova/nova.conf,
> and warn or handle directly.

Hi,

After I got the error of running the script openstack-nova-db-setup, I looked at the script and saw the main part, nova-manage db sync, where it creates the tables as you've said.  I've ran that several times and it never create once the table nova.migrate_version table.  The nova-manage db sync didn't warn me about DB on different host.  On a side note, keystone-manage db_sync doesn't also create the table migrate_version while glance-manage db_sync ONLY creates the table migrate_version.  Should I file a separate bug for each of those packages?

Thanks.
Comment 3 Pádraig Brady 2012-04-26 11:59:37 EDT
No need to file separately,
especially as the db management is being consolidated to a single script.
I'll look into the remote DB issue.
Comment 4 Tommy P 2012-04-27 04:10:23 EDT
I've done a lot more extensive testing again tonight and it seems that they do now create migrate_version table in each of the databases.  (Perhaps I was a bit tired last night.)  However, I also have some good news for the glance database.  I think it fails to create other tables because the order of execution is messed up.  I've tried it in Ubuntu 12.04 LTS and it also have problems creating the tables for glance.  It needs to create tables in the order as shown (but it doesn't for some reason) from /usr/lib/python2.7/site-packages/glance/registry/db/migrate_repo/versions:

001_add_images_table.py                       
002_add_image_properties_table.py
003_add_disk_format.py
004_add_checksum.py
005_size_big_integer.py
006_key_to_name.py
007_add_owner.py
008_add_image_members_table.py
009_add_mindisk_and_minram.py
010_default_update_at.py
011_make_mindisk_and_minram_notnull.py
012_id_to_uuid.py
013_add_protected.py

F17 didn't have debugging info but Ubuntu did debug dump on error.  From that error, I traced it down to why the table creation fails because of the foreign key constraint (which I think it maybe the same with F17):

[root@v-fedora17-d versions]# grep -i 'foreign' *.py
002_add_image_properties_table.py:    Column, ForeignKey, Index, MetaData, Table, UniqueConstraint)
002_add_image_properties_table.py:        Column('image_id', Integer(), ForeignKey('images.id'), nullable=False,
006_key_to_name.py:        Column('image_id', Integer(), ForeignKey('images.id'), nullable=False,
008_add_image_members_table.py:        Column('image_id', Integer(), ForeignKey('images.id'), nullable=False,
012_id_to_uuid.py:            FOREIGN KEY(image_id) REFERENCES images (id)
012_id_to_uuid.py:            FOREIGN KEY(image_id) REFERENCES images (id)
012_id_to_uuid.py:            FOREIGN KEY(image_id) REFERENCES images (id)
012_id_to_uuid.py:            FOREIGN KEY(image_id) REFERENCES images (id)
012_id_to_uuid.py:    foreign_keys = _get_foreign_keys(t_images,
012_id_to_uuid.py:    for fk in foreign_keys:
012_id_to_uuid.py:    for fk in foreign_keys:
012_id_to_uuid.py:    foreign_keys = _get_foreign_keys(t_images,
012_id_to_uuid.py:    for fk in foreign_keys:
012_id_to_uuid.py:    for fk in foreign_keys:
012_id_to_uuid.py:def _get_foreign_keys(t_images, t_image_members, t_image_properties):
012_id_to_uuid.py:    """Retrieve and return foreign keys for members/properties tables."""
012_id_to_uuid.py:    image_members_fk_name = list(t_image_members.foreign_keys)[0].name
012_id_to_uuid.py:    image_properties_fk_name = list(t_image_properties.foreign_keys)[0].name
012_id_to_uuid.py:    fk1 = migrate.ForeignKeyConstraint([t_image_members.c.image_id],
012_id_to_uuid.py:    fk2 = migrate.ForeignKeyConstraint([t_image_properties.c.image_id],
Comment 5 Tommy P 2012-04-27 04:15:09 EDT
PS: I have no clue about Python so I can't debug any further :)
Comment 6 Pádraig Brady 2012-04-27 07:23:39 EDT
I'm a little confused.
Are the nova and keystone tables OK?
Only the glance database is messed up?

Was glance started before openstack-gkance-db-setup was run?
glance seems to have a quirk where it will create the tables itself if started,
before the database is initialized.
Eoghan, I think we should be patch glance, at least in the rpm, to stop doing that?

I just confirmed that glance works against a _local_ database correctly by doing:

# for svc in api registry; do service openstack-glance-$svc stop; done
# openstack-db --drop --service glance
# openstack-db --init --service glance
# for svc in api registry; do service openstack-glance-$svc start; done
# glance index
Comment 7 Tommy P 2012-04-27 14:46:04 EDT
Hi, I apologize for being vague.  Yes, the nova and the keystone databases are OK now.  I didn't run the openstack-glance-db-setup.  I only ran the glance-manage db_sync. I'll trying running your test above with the remote DB server later when I get home.  Thanks.
Comment 8 Matthias Runge 2012-09-01 16:02:36 EDT
Any progress here? 

I could reproduce that an a fresh installation
following:

https://fedoraproject.org/wiki/Getting_started_with_OpenStack_on_Fedora_17

(basically 
1. install mysql-server
2. mysql_secure_installation
3. openstack-db --init --service nova
Comment 9 Matthias Runge 2012-09-01 16:04:31 EDT
[root@turing ~]# rpm -q -f /bin/nova-manage
openstack-nova-common-2012.1.1-15.fc17.noarch

[root@turing ~]# rpm -q -f /usr/bin/openstack-db
openstack-utils-2012.1-2.fc17.noarch
Comment 10 Matthias Runge 2012-09-01 16:35:39 EDT
running nova-manage db sync by hand works as expected.
Comment 11 Pádraig Brady 2012-09-02 04:26:15 EDT
Interesting. I usually let `openstack-db --init` do the mysql installation.
The previous manual install must be messing with things?
Note also that glance has been since modified to not auto create the DB,
and so be immune to startup order issues.
Comment 12 Matthias Runge 2012-09-05 05:35:42 EDT
I thought, the initial and mine are the same. Currently, I'm not sure anymore on that.

My setup is just one computer, database on the same host, just setting up nova:
as written in the getting started guide for F17:
sudo openstack-db --service nova --init

I guess, the error(?) is in the openstack-db script, expecting nova.migrate_version to be exist.
Comment 13 Pádraig Brady 2012-09-06 09:51:42 EDT
Matthias you're noticing a separate bug I think.
Please add the mysql-server version you used to: bug #854981
I'l close this bug as it looks like issues with remote databases which we've tracked elsewhere
Comment 14 葛国勇 2014-01-25 05:47:32 EST
check if  pre step " openstack-config --set /etc/nova/nova.conf \
  database connection mysql://nova:NOVA_DBPASS@controller/nova" is right?

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