Looks like there are differences in DBs created before and after review 324897. After excluding non-relevant differences:
$ diff cinder.sql cinder-old.sql
181,185c181,183
< `volume_type_id` varchar(36) DEFAULT NULL,
< `encryption_id` varchar(36) NOT NULL,
< PRIMARY KEY (`encryption_id`),
< KEY `volume_type_id` (`volume_type_id`),
< CONSTRAINT `encryption_ibfk_1` FOREIGN KEY (`volume_type_id`) REFERENCES `volume_types` (`id`)
---
> `volume_type_id` varchar(36) NOT NULL,
> `encryption_id` varchar(36) NOT NULL DEFAULT '',
> PRIMARY KEY (`encryption_id`)
532c530
< `volume_id` varchar(36) DEFAULT NULL,
---
> `volume_id` varchar(36) NOT NULL,
548c546
< KEY `volume_id` (`volume_id`),
---
> KEY `snapshots_volume_id_fkey` (`volume_id`),
550,551c548,549
< CONSTRAINT `snapshots_ibfk_1` FOREIGN KEY (`volume_id`) REFERENCES `volumes` (`id`),
< CONSTRAINT `snapshots_ibfk_2` FOREIGN KEY (`cgsnapshot_id`) REFERENCES `cgsnapshots` (`id`)
---
> CONSTRAINT `snapshots_ibfk_1` FOREIGN KEY (`cgsnapshot_id`) REFERENCES `cgsnapshots` (`id`),
> CONSTRAINT `snapshots_volume_id_fkey` FOREIGN KEY (`volume_id`) REFERENCES `volumes` (`id`)
746c744
< KEY `volume_type_id` (`volume_type_id`),
---
> KEY `volume_type_extra_specs_ibfk_1` (`volume_type_id`),
1. Additional index and constraint.
2. Difference in nullability of the column.
3. Difference in naming of a constraint.
4. Difference in naming of a constraint where same name indicates different constraint (oh!).
5. Difference in naming of a constraint.
I'm concerned the most about 3, 4, 5 - we will not have a reliable way of dropping these constraints in future migrations.
I think we should make an exception and merge fixes to that migration in particular.
Fix proposed to branch: master
Review: https:/