openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #11186
Re: [Glance] Replication implementations
> > 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?
Of course, the other way of looking at this would be to just follow the
lead of EC2 itself and not provide an image ID portability across regions.
Though I think we can do better than that by compressing the UUID in a
predictable way.
Cheers,
Eoghan
References