yahoo-eng-team team mailing list archive

[OpenStack Infra <1758057@xxxxxxxxxxxxxxxxxx>]

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.sharma@xxxxxxxxxxxxxxxxxx>
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 <dstbtgagt@xxxxxxxxxxx>
    
    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