openstack team mailing list archive

[Eoghan Glynn <eglynn@xxxxxxxxxx>]

> 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