When creating uuid-based entities we can duplicate UUIDs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Compute (nova) |
Fix Released
|
Undecided
|
Mike Chen |
Bug Description
It is possible to create two different resource providers (and probably other entities) with the same UUID by creating one with '-' and the other without. This is because in both json schema and ovo validate UUIDs using the same route (different code but same concept): with or without - is okay.
Then, we save these strings into a column in the database which is not a uuid type, instead it is varchar 36.
Thus we can make this happen (gabbi format):
-=-=-
# Some tests to see if different representations of the
# same uuid result in different resource providers.
fixtures:
- APIFixture
defaults:
request_
accept: application/json
tests:
- name: create dashed
POST: /resource_providers
data:
name: dashed
uuid: b7c31381-
- name: create not dashed
POST: /resource_providers
data:
name: not dashed
uuid: b7c313810cd6421
- name: check length
GET: /resource_providers
response_
# This may be should be 1 but on current master is 2
$
-=-=-
We might be able to get away with this not being a problem except that there is one place where we expected a dashed uuid for resource providers: in the JSON schema for PUTting allocations in the dict format: https:/
This happened because I couldn't figure out how to use a format checker for a PatternProperties and wrote a pattern only accepting a 36 length UUID.
This means we've got at least two potential problems:
* we can create a resource provider for which we can't write allocations (unless we use the older list style)
* clients have the potential to think they are using the same UUID when the placement server thinks they are not
We can solve this in a few different ways, this list is not mutually exclusive:
* do nothing, expect people to do the right thing
* change the PatternProperty on allocation put to make dash optional
* continue accepting non-dashed input, but always dash them early in processing
* reject non-dashed input everywhere
And I haven't looked into consumer uuids, but I suspect there's some ambiguity there too.
The root issue here, in case it is not clear, is that code in the wild that we don't control that is creating and stringifying UUID may be creating the non-dashed format.
Changed in nova: | |
assignee: | nobody → Rajat Sharma (tajar29) |
Changed in nova: | |
assignee: | Rajat Sharma (tajar29) → Chen (chenn2) |
My take is that we should start by fixing this in a way that doesn't require a microversion. Namely, continue accepting what we accept (no schema changes etc.) but normalize the values as they come in.
Given that it is pretty unlikely that this issue has manifested in the wild, don't do anything to try to clean it up until/unless someone demands it.