Reviewed: https://review.openstack.org/567191 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=d27d8e44a3845349990fca81de805538f01480bf Submitter: Zuul Branch: master
commit d27d8e44a3845349990fca81de805538f01480bf Author: rajat29 <rajat.sha...@nectechnologies.in> Date: Wed May 9 16:15:20 2018 +0530 Normalize dashless 'resource provider create' uuid When creating resource provider with '--uuid' argument, nova accept uuid without dash('-') too, which some time results in, resource provider with same uuid i.e one with dash and one without. This patch attempts to fix it by transforming dashless UUID into dashed one before inserting it into the database. Co-Authored-By: Chen <dstbtg...@foxmail.com> Change-Id: I2685eb65907adbd22b2d09264b110692e100eaf9 Closes-Bug: #1758057 ** Changed in: nova Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1758057 Title: When creating uuid-based entities we can duplicate UUIDs Status in OpenStack Compute (nova): Fix Released 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_headers: x-auth-token: admin accept: application/json content-type: application/json openstack-api-version: placement latest tests: - name: create dashed POST: /resource_providers data: name: dashed uuid: b7c31381-0cd6-421c-a2d2-009d645615dc - name: create not dashed POST: /resource_providers data: name: not dashed uuid: b7c313810cd6421ca2d2009d645615dc - name: check length GET: /resource_providers response_json_paths: # This may be should be 1 but on current master is 2 $.resource_providers.`len`: 1 -=-=- 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://github.com/openstack/nova/blob/master/nova/api/openstack/placement/schemas/allocation.py#L80 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. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1758057/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp