EC2 and OS Image APIs use inconsistent IDs
Bug #885090 reported by
justinsb
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Invalid
|
Wishlist
|
Unassigned | ||
ec2-api |
Invalid
|
Undecided
|
Unassigned |
Bug Description
When retrieving images through the EC2 API, the image id looks like "ami-00000001"; when using the OS API it looks like "1". Sadly the EC2 API only accepts the "ami-00000001" format, which means that if you query the OS API to get the image (which you have to do to get the metadata) you then can't use that image API to create an instance (which you have to do to specify an SSH key). While I can perform the same mapping that the EC2 API no doubt does under the covers, I really shouldn't have to - I suggest that the EC2 API should be returned in the metadata, or the EC2 API create call should accept an OS Image Id.
Changed in nova: | |
importance: | Undecided → Wishlist |
status: | Won't Fix → Confirmed |
Changed in nova: | |
assignee: | nobody → Nova EC2 API (nova-ec2-api) |
tags: | added: ec2 |
Changed in ec2-api: | |
status: | New → Invalid |
Changed in nova: | |
status: | Confirmed → Invalid |
To post a comment you must log in.
You're probably going to be even more unhappy when I tell you Glance moved over to uuids (which OSAPI directly exposes) but we have a mapping layer in the database to preserve EC2's mapping to hex ids. I don't think this is a bug, as we need to be able to move OSAPI forward without worrying about EC2. EC2 is a compatibility layer (defined completely out of our control) intended for users transitioning over to OSAPI (once that stabilizes).