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. Change-Id: I5d7fe41f5680a48adf12723a0a4a82fd5ec35d58 blueprint: generation-from-create-provider
4.3 KiB
Return Generation from Resource Provider Creation
https://blueprints.launchpad.net/nova/+spec/generation-from-create-provider
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.
Alternatives
- 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. - 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
None
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 respond200
. - 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
None
Notifications impact
None
Other end user impact
None
Performance Impact
None
Other deployer impact
None
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.
Implementation
Assignee(s)
- Primary assignee:
-
efried
Work Items
- Add a new micro-versioned handler in
nova.api.openstack.placement.handlers.resource_provider.create_resource_provider
to return200
with the provider payload. - Update the placement-api-ref.
Dependencies
None
Testing
Gabbits will be added to validate the new behavior.
Documentation Impact
- Update the placement API reference section for POST /resource_providers.
- Update the REST API Version History.
References
- The POST /resource_providers API documentation.
- bug 1746075
- The GET /resource_providers/{uuid} API documentation.
- The placement REST API Version History documentation.
History
Release Name | Description |
---|---|
Rocky | Introduced |