Synnefo

Apart from this not being visible in the models, is it causing any actual problems?

Both update_metadata and create_metadata_item check for existing meta with the same key. You should not be able to create two meta with the same key on the same server or image.

Checking for existence before adding the row in the DB has a race, and this has actually happened. What do you do if two clients at exactly the same time try to add the same metadata key to the same VM? The API adds two same rows in the table for image metadata.
When this happens the DB is in inconsistent state, and the API barfs -- ask [kpap].

I think the best thing to do would be:
a) enforce the restriction in the DB [in general, every restriction should be enforce in the DB if possible]
b) to avoid races, catch the DB exception when the API attempts to insert a duplicate row, and return an appropriate cloud fault.
c) related to (b): Does the API prescribe a specific error code when trying to insert a duplicate metadata key?

Maybe this is related to the transactions ticket then? It was previously discussed that each API call should run in its own transaction. Race conditions like this one exist all over the API and in most cases will cause a 500 fault.

Regarding c, the OpenStack API allows passing existing keys and in that case replaces the old values.

The transactions ticket is pending and will be merged, OK, but still, we should make an effort to enforce the constraints as much as possible in the DB itself. Please update the constraints in the ImageMetadata model.