yahoo-eng-team team mailing list archive

[Chris Dent <cdent+lp@xxxxxxxxxxxxx>]

Public bug reported:

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.

** Affects: nova
     Importance: Undecided
         Status: Triaged


** Tags: placement

-- 
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):
  Triaged

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