> Current warts: > ... > - maintaining amazon ec2 ids across regions requires twiddling the > nova database where this mapping is stored
Hi Mikal, We discussed that nova s3_images table earlier in the week on IRC. Now at the time, I wasn't fully clear on the mechanics of the glance UUID -> EC2-style image ID mapping. I've had a dig into the code since then and it turns out that the EC2 image ID is effectively determined by an auto_increment column in the s3_images table. So there is nothing globally significant about that ID, in fact it's completely determined by the insertion order into the nova s3_images table, which occurs *on demand* the first time the image is being referenced in an EC2-related context (for example the first call to DescribeImages after the image has been uploaded to glance). For example in a fresh openstack deployment, if three images are uploaded with types aki, ari & aki respectively, the first EC2-related reference to the images will result in the following EC2 IDs always being generated: aki-00000001 ari-00000002 ami-00000003 Now, if the underlying glance images are migrated to another long-standing openstack deployment, it's likely that there are already multiple images referenced in the local s3_images table, so that the identifiers a[krm]i-0000000[1-3] are already taken. So the way things currently stand, the EC2 image ID isn't really capable of migration. I was thinking however that we should change the EC2 image generation logic, so that there is a reproducible glance UUID -> EC2 mapping (with a small chance of collision). This change would allow the same EC2 ID to be generated in multiple regions for a given glance UUID (modulo collisions). Would that be helpful in your migration use-case? Cheers, Eoghan _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
