Comment 6 for bug 1061166

From what I can gather the 107 migration only copies the instance's ID and UUID to the new mapping table, but leaves the other columns NULL, specifically 'deleted'.

In Folsom, an ec2 describe instances call will check that the instances.id <-> uuid mapping exists in the instances_id_mapping table and create one if it does not find one.

The query that checks the instances_id_mapping table has a 'deleted=0' constraint. In this case, all of the copied mappings have a NULL value here. Finding no mapping, it creates a new one and throws the whole thing off.

It makes sense that this works fine on fresh Folsom installs, because new instances get a new mapping created in this empty table with the appropriate columns filled.

There is still a relationship between instances.id and instance_id_mappings.id, and the duplicate entries being created in the mapping table throws that relationship off (after the table has duplicate entires created, new instances EC2 IDs are also off). I'm not sure if there needs to be a FK constraint between instances.id and instance_id_mappings.id to ensure that relationship is in-tact, even if the mappings table is being polluted with duplicates.