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.
Related fix proposed to branch: master
Review: https:/