yahoo-eng-team team mailing list archive

[Eric Fried <efried@xxxxxxxxxx>]

Public bug reported:

Placement has a few APIs which affect resource provider generation, but
which do not accept the current resource provider generation and
therefore cannot ensure consistency.  They are as follows:

DELETE /resource_providers/{u}/inventories
DELETE /resource_providers/{u}/traits

POST /allocations

PUT /allocations/{c}
DELETE /allocations/{c}

As an example of how this is broken:

- X wants to remove all of provider {u}'s inventory in resource class VGPU.  He GETs inventory at generation 1, which happens to contain *only* VGPU.
- Y wants to add some SRIOV_NET_VF inventory to {u}.  He GETs inventory at generation 1, adds the SRIOV_NET_VF inventory, and PUTs it back.  The server increments the generation to 2, and the provider now has both VGPU and SRIOV_NET_VF inventory.
- X, thinking the provider only has VGPU resource, invokes DELETE /resource_providers/{u}/inventories, which succeeds, thereby blowing away the SRIOV_NET_VF inventory.

Note that in the case of DELETE /resource_providers/{u}/inventories and
.../traits, there is an alternative, PUT <empty>, which *does* accept
the provider generation.

For the allocations APIs, there is no alternative.  Though it could be
argued that it should not be necessary to send generation with the
allocations APIs.

** Affects: nova
     Importance: Undecided
         Status: New


** 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/1746373

Title:
  Placement APIs with missing conflict detection

Status in OpenStack Compute (nova):
  New

Bug description:
  Placement has a few APIs which affect resource provider generation,
  but which do not accept the current resource provider generation and
  therefore cannot ensure consistency.  They are as follows:

  DELETE /resource_providers/{u}/inventories
  DELETE /resource_providers/{u}/traits

  POST /allocations

  PUT /allocations/{c}
  DELETE /allocations/{c}

  As an example of how this is broken:

  - X wants to remove all of provider {u}'s inventory in resource class VGPU.  He GETs inventory at generation 1, which happens to contain *only* VGPU.
  - Y wants to add some SRIOV_NET_VF inventory to {u}.  He GETs inventory at generation 1, adds the SRIOV_NET_VF inventory, and PUTs it back.  The server increments the generation to 2, and the provider now has both VGPU and SRIOV_NET_VF inventory.
  - X, thinking the provider only has VGPU resource, invokes DELETE /resource_providers/{u}/inventories, which succeeds, thereby blowing away the SRIOV_NET_VF inventory.

  Note that in the case of DELETE /resource_providers/{u}/inventories
  and .../traits, there is an alternative, PUT <empty>, which *does*
  accept the provider generation.

  For the allocations APIs, there is no alternative.  Though it could be
  argued that it should not be necessary to send generation with the
  allocations APIs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1746373/+subscriptions