Ask Your Question
0

Unknown field volumes.source_volid after upgrade to Grizzly on Ubuntu

asked 2013-06-11 02:04:33 -0500

tudor gravatar image

updated 2013-06-11 13:02:24 -0500

smaffulli gravatar image

I'm running Ubuntu 12.04 LTS with the OpenStack Grizzly repository after upgrading from Folsom.

I seem to be getting errors accessing volumes. To check, I logged all the queries in mysql and when I did :

cinder list

The following query was logged:

SELECT volumes.created_at AS volumes_created_at, volumes.updated_at AS volumes_updated_at, volumes.deleted_at AS volumes_deleted_at, volumes.deleted AS volumes_deleted, volumes.id AS volumes_id, volumes.ec2_id AS volumes_ec2_id, volumes.user_id AS volumes_user_id, volumes.project_id AS volumes_project_id, volumes.snapshot_id AS volumes_snapshot_id, volumes.host AS volumes_host, volumes.size AS volumes_size, volumes.availability_zone AS volumes_availability_zone, volumes.instance_uuid AS volumes_instance_uuid, volumes.mountpoint AS volumes_mountpoint, volumes.attach_time AS volumes_attach_time, volumes.status AS volumes_status, volumes.attach_status AS volumes_attach_status, volumes.scheduled_at AS volumes_scheduled_at, volumes.launched_at AS volumes_launched_at, volumes.terminated_at AS volumes_terminated_at, volumes.display_name AS volumes_display_name, volumes.display_description AS volumes_display_description, volumes.provider_location AS volumes_provider_location, volumes.provider_auth AS volumes_provider_auth, volumes.volume_type_id AS volumes_volume_type_id, volumes.source_volid AS volumes_source_volid, volume_types_1.created_at AS volume_types_1_created_at, volume_types_1.updated_at AS volume_types_1_updated_at, volume_types_1.deleted_at AS volume_types_1_deleted_at, volume_types_1.deleted AS volume_types_1_deleted, volume_types_1.id AS volume_types_1_id, volume_types_1.name AS volume_types_1_name, volume_metadata_1.created_at AS volume_metadata_1_created_at, volume_metadata_1.updated_at AS volume_metadata_1_updated_at, volume_metadata_1.deleted_at AS volume_metadata_1_deleted_at, volume_metadata_1.deleted AS volume_metadata_1_deleted, volume_metadata_1.id AS volume_metadata_1_id, volume_metadata_1.`key` AS volume_metadata_1_key, volume_metadata_1.value AS volume_metadata_1_value, volume_metadata_1.volume_id AS volume_metadata_1_volume_id
FROM volumes LEFT OUTER JOIN volume_types AS volume_types_1 ON volumes.volume_type_id = volume_types_1.id AND volume_types_1.deleted = 0 LEFT OUTER JOIN volume_metadata AS volume_metadata_1 ON volume_metadata_1.volume_id = volumes.id AND volume_metadata_1.deleted = 0
WHERE volumes.deleted = 0 AND volumes.host = 'host'

I put this query into mysql against the cinder database and it returned:

Unknown column 'volumes.source_volid' in 'field list'

Indeed, this field doesn't appear anywhere in any databases. This, to me, sounds like "nova-manage db sync" didn't work after the upgrade. (Running it again returns no message or error.)

Is there another command I'm supposed to run to add the fields that are missing?

edit retag flag offensive close merge delete

1 answer

Sort by ┬╗ oldest newest most voted
0

answered 2013-06-11 22:58:34 -0500

tudor gravatar image

It appears that in order to upgrade correctly, one also needs to run as sudo:

cinder-manage db sync

This returned:

2013-06-12 13:55:27     INFO [migrate.versioning.api] 2 -> 3... 
2013-06-12 13:55:27     INFO [migrate.versioning.api] done
2013-06-12 13:55:27     INFO [migrate.versioning.api] 3 -> 4... 
2013-06-12 13:55:28     INFO [004_volume_type_to_uuid] Created foreign key volume_type_extra_specs_ibfk_1
2013-06-12 13:55:28     INFO [migrate.versioning.api] done
2013-06-12 13:55:28     INFO [migrate.versioning.api] 4 -> 5... 
2013-06-12 13:55:29     INFO [migrate.versioning.api] done
2013-06-12 13:55:29     INFO [migrate.versioning.api] 5 -> 6... 
2013-06-12 13:55:29     INFO [migrate.versioning.api] done
2013-06-12 13:55:29     INFO [migrate.versioning.api] 6 -> 7... 
2013-06-12 13:55:30     INFO [migrate.versioning.api] done
2013-06-12 13:55:30     INFO [migrate.versioning.api] 7 -> 8... 
2013-06-12 13:55:30     INFO [migrate.versioning.api] done
2013-06-12 13:55:30     INFO [migrate.versioning.api] 8 -> 9... 
2013-06-12 13:55:30     INFO [migrate.versioning.api] done

After this I could access my volumes again. :-)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

Stats

Asked: 2013-06-11 02:04:33 -0500

Seen: 203 times

Last updated: Jun 11 '13