Return Generation from Resource Provider Creation

To facilitate opaqueness of resource provider generation internals, we need to return the (initial) generation when a provider is created. For consistency with other APIs, we will do this by returning the entire resource provider record (which includes the generation) from POST /resource_providers.

Problem description

As described in bug 1746075, placement API consumers have an awkward time handling the initial generation of a newly-created resource provider. The Nova report client deals with it by assuming the initial generation is 0, which violates the intended opaqueness of the generation in the API.

Use Cases

As a consumer of the placement API, I want to be able to glean the initial generation value of a freshly-created provider while preserving its opaqueness.

Proposed change

In a new microversion, the POST /resource_providers API shall, upon success, return 200 with a payload representing the resource provider record. This payload will be identical to what would be returned by GET /resource_providers/{uuid} at the current microversion.


  1. Immediately follow POST /resource_providers with GET /resource_providers/{uuid}, using URI in the location header returned by the POST. This would work fine, but it’s an extra REST call. The proposed implementation is more convenient.

  2. Assume the initial generation of a provider is 0. While this happens to be true, the assumption violates the intended opaqueness of the generation in the API.

Data model impact


REST API impact

See Proposed change. The input spec is identical except for the Openstack-API-Version header. The difference in the response is:

  • On success, instead of 201, the new microversion will respond 200.

  • On success, instead of an empty body, the new microversion will include a JSON payload representing the record of the newly-created resourcec provider, in a format identical to the response of GET /resource_providers/{uuid} at the current microversion.

Security impact


Notifications impact


Other end user impact


Performance Impact


Other deployer impact


Developer impact

Developers have a convenient way to glean the generation of a newly-created provider without additional API calls.

Upgrade impact

Until their minimum required placement microversion is at least the microversion produced by this spec, clients implementing this feature will need to fall back to one of the Alternatives when 406 is received.



Primary assignee:


Work Items

  • Add a new micro-versioned handler in nova.api.openstack.placement.handlers.resource_provider.create_resource_provider to return 200 with the provider payload.

  • Update the placement-api-ref.




Gabbits will be added to validate the new behavior.

Documentation Impact




Release Name