Migrations do not populate volume_id_mappings and instance_id_mappings completely

Bug #1062474 reported by Adam Gandelman on 2012-10-05
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)

Bug Description


These two migrations create tables that easily map volume and instance IDs to UUIDs. Each have 6 columns: id, uuid, created_at, updated_at, deleted_at, deleted. Only the 'id' and 'uuid' column get populated with data copied from the volumes or instances table in the migration that creates them. From what I can tell, none of these fields are currently being used by code anywhere in Folsom, but this has already introduced a nasty Bug #1061166.

If the plan is to be able to query this info from this table in Grizzly, they should be fully populated with data for existing instances. If there is no plan to make use of them, they should be dropped.

Additionally, there should probably be some uniqueness constraints on those tables to ensure these mappings stay consistent if similar bugs exist elsewhere in the code base.

Tags: db Edit Tag help
affects: nova (Ubuntu) → nova
Adam Gandelman (gandelman-a) wrote :

This is also an issue for the volume_id_mappings and snapshot_id_mappings. It seems the same workaround for Bug #1061166 can be used there, too, but the tables should probably be populated correctly if that data is intended to be used.

Michael Still (mikal) on 2012-10-15
Changed in nova:
status: New → Confirmed
importance: Undecided → Critical
Changed in nova:
assignee: nobody → Diganta kumar sahoo (mail2digant)
Changed in nova:
status: Confirmed → In Progress
Changed in nova:
status: In Progress → Fix Committed

Fix proposed to branch: master
Review: https://review.openstack.org/16292

Changed in nova:
status: Fix Committed → In Progress
Thierry Carrez (ttx) wrote :

Needs someone else to pick it up, review expired.

Changed in nova:
assignee: Diganta kumar sahoo (mail2digant) → nobody
importance: Critical → High
milestone: none → grizzly-2
status: In Progress → Triaged
Thierry Carrez (ttx) on 2013-01-09
Changed in nova:
milestone: grizzly-2 → grizzly-3
Guangyu Suo (yugsuo) on 2013-01-10
Changed in nova:
assignee: nobody → Yug Suo (yugsuo)
Thierry Carrez (ttx) on 2013-02-21
Changed in nova:
milestone: grizzly-3 → grizzly-rc1
Guangyu Suo (yugsuo) on 2013-03-13
Changed in nova:
status: Triaged → In Progress
Thierry Carrez (ttx) wrote :

@Yug Suo: Please let us know if you're making progress on that -- if not please unassign yourself and set this back to Triaged.

Changed in nova:
status: In Progress → Triaged
tags: added: db
Changed in nova:
milestone: grizzly-rc1 → havana-1
Russell Bryant (russellb) wrote :

Removed assignee, as it doesn't appear to be in progress

Changed in nova:
milestone: havana-1 → none
assignee: Guangyu Suo (yugsuo) → nobody
ugvddm (271025598-9) on 2013-08-10
Changed in nova:
assignee: nobody → ugvddm (271025598-9)
ugvddm (271025598-9) on 2013-08-10
Changed in nova:
assignee: ugvddm (271025598-9) → nobody
Shane Wang (shane-wang) on 2013-08-23
Changed in nova:
assignee: nobody → Shane Wang (shane-wang)
Shane Wang (shane-wang) wrote :

This bug seems invalid now.

The reason is the type of id in volumes has been changed from int to string(36) so it can fit into uuid in volumes_id_mappings.
So can the id in snapshots.

For instances, there is a uuid which could be assigned to uuid in instances_id_mappings.

Changed in nova:
assignee: Shane Wang (shane-wang) → nobody
Joe Gordon (jogo) on 2014-06-12
Changed in nova:
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers