The placement project has published the API reference
in its own repository and the related jobs for the nova project
has been removed since Ia4680f24d78af1260f2f0106a458b78a079c1287.
So remove the files and definitions related to
the placement API reference in the nova repository.
Change-Id: Ia43b958a28e7e763e7ecb29e06f8d21d2b9a850f
The schema accepts the (resource provider) 'generation' key in the
resource provider section of the allocations dictionary in the POST
/allocations/{consumer_uuid} request payload. As with PUT
/allocations/{consumer_uuid}, it is ignored. This was missing from the
API reference.
Change-Id: I2586875a60aba7a566f6c1b61ded133b8749031c
/reshaper provides a way to atomically modify some allocations and
inventory in a single transaction, allowing operations like migrating
some inventory from a parent provider to a new child.
A fair amount of code is reused from handler/inventory.py, some
refactoring is in order before things get too far with that.
In handler/allocation.py some code is extracted to its own methods
so it can be reused from reshaper.py.
This is done as microversion 1.30.
A suite of gabbi tests is provided which attempt to cover various
failures including schema violations, generation conflicts, and
data conflicts.
api-ref, release notes and rest history are updated
Change-Id: I5b33ac3572bc3789878174ffc86ca42ae8035cfa
Partially-Implements: blueprint reshape-provider-tree
This patch will replace all GB with GiB and MB with MiB
to have a consistent use of units in the compute API reference
and the placement API reference.
Co-Authored-By: Takashi Natsume <natsume.takashi@lab.ntt.co.jp>
Change-Id: Ie40413752b591b222ff29dbe975ddd7d10638eca
Closes-Bug: #1752340
About "PUT /resource_providers/{uuid}/aggregates"
in the Placement API reference,
the example of the response body in microversion 1.1 - 1.18 is missing.
So add it.
Change-Id: Ic3dc665124ae7927cfa20cf70a08c39b856b8961
Closes-Bug: #1786759
Mention that if any nonexistent aggregate uuids are provided, those
aggregates will be created automatically first during the update call.
I think this is a good addition since in fact I was much confused how
the aggregates can be created in the first place when playing with
the placement APIs.
Change-Id: I2f86715a21784eb974b73fc3edc74eedd73ad48b
In the placement API reference, there is a separate section for
"microversions 1.19 -" for both List and Update resource provider
aggregates, so there's no need for the resource_provider_generation
field to mention that it's "New in version 1.19" in those sections.
Change-Id: I3fd02f21d4af11633c4aeb33925c279a1c3b4abd
Add description for nested resource providers
in allocation candidates, Placement API microversion 1.29
in the Placement API reference.
Change-Id: I22c2068ae860c1ef2cbdb0801e85a40acc2a097a
Implements: blueprint nested-resource-providers-allocation-candidates
Due to a regression in I8624e194fe0173531c5aa2119c903e3c68b8c6cd, the
min_version on the parent_provider_uuid response parameter was missing
and is added back here. For sanity reasons, the variables are renamed
and substitution anchor usage is dropped.
To recap the microversions:
1.14
----
parent_provider_uuid and root_provider_uuid were added to the
responses for:
* GET /resource_providers (list)
* GET /resource_providers/{uuid} (show)
* PUT /resource_providers/{uuid} (update)
parent_provider_uuid was added to the request for:
* POST /resource_providers (create)
* PUT /resource_providers/{uuid} (update)
1.20
----
We started returning a response body from
POST /resource_providers (create) which included
parent_provider_uuid and root_provider_uuid but the parameters
are not versioned in that case since the entire response is
versioned for 1.20.
Change-Id: I6c9a1072fa2a59e408472f1a4b52b3a8c6a9b343
Closes-Bug: #1779700
In the "List allocation candidates" API,
the 'traits' parameter is missing.
So add it and update examples.
Change-Id: I4a307759f9e8fa80d003d92142f8e99b2c09c9fe
Partial-Bug: #1778670
Add description for placement microversion 1.26
in the following APIs in the placement API reference.
* PUT /resource_providers/{uuid}/inventories
* PUT /resource_providers/{uuid}/inventories/{resource_class}
Up to microversion 1.25, the value of 'reserved' has to be less
than the value of 'total' in the request.
Starting from microversion 1.26, it has to be less than or
equal to the value of 'total'.
Change-Id: Id1857abf323c9776ab8fe957202848ff7ab3fbd2
Closes-Bug: #1783380
Address various minor issues from
https://review.openstack.org/#/c/565604/
Change-Id: I69df4c8d8c4b8813f78aeeb46f7b788d36238d35
Blueprint: add-consumer-generation
Error handling to raise the exception 409 while deleting
the parent if it has children.
Closes-Bug: #1770636
Change-Id: I87df68992e4e635f009974f5205ca4919a4f2576
This patch adds new placement API microversion for handling consumer
generations.
Change-Id: I978fdea51f2d6c2572498ef80640c92ab38afe65
Co-Authored-By: Ed Leafe <ed@leafe.com>
Blueprint: add-consumer-generation
According to the spec [1] the version discovery doc must have a status
and links for each version. For the primary version the status value
should be 'CURRENT'. For placement the version discovery doc and "self"
are the same thing, so the provided "self" href looks redundant, but it
makes keystoneauth1 happy when doing version discovery.
In placement, since there is only one version at the moment, set status
to CURRENT.
Add a gabbi test that verifies the presence of both fields and values.
Without these fields, use of placement with a client that follows the
documented version discovery process will fail to work.
As the version doc is not considered microversioned[2] and in any case
this is making version discovery work where it didn't before, this is
not a candidate for a microversion and can be backported to the
beginning of placement's history if we like.
I've updated the api-ref docs. In the process I made the max
microversion in the sample discovery doc a bit more realistic and
in alignment with these modern times.
[1] http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html#version-discovery
[2] http://eavesdrop.openstack.org/irclogs/%23openstack-sdks/%23openstack-sdks.2018-06-13.log.html#t2018-06-13T13:40:12
Change-Id: Ie602ab1768efbf103563d8f6b9d28965fc81021a
Closes-Bug: #1776668
This just updates the POST/PUT resource providers API reference
for the parent_provider_uuid field to mention it can't be changed
to another parent provider once set.
Change-Id: Ie733517a8b413ec0b54d217d779bb7405e162e28
In a new microversion, the GET /allocation_candidates API now accepts
granular resource request syntax:
?resourcesN=...&requiredN=...&member_ofN=...&group_policy={isolate|none}
Change-Id: I4e99974443aa513fd9f837a6057f67d744caf1b4
blueprint: granular-resource-requests
This ensures we have version-specific references to other projects [1].
Note that this doesn't mean the URLs are actually valid - we need to do
more work (linkcheck?) here, but it's an improvement nonetheless.
[1] https://docs.openstack.org/openstackdocstheme/latest/#external-link-helper
Change-Id: Ifb99e727110c4904a85bc4a13366c2cae300b8df
Adds a new placement API microversion that supports specifying multiple
member_of parameters to the GET /resource_providers and GET
/allocation_candidates API endpoints.
When multiple member_of parameters are found, they are passed down to
the ResourceProviderList.get_by_filters() method as a list. Items in
this list are lists of aggregate UUIDs.
The list of member_of items is evaluated so that resource providers
matching ALL of the member_of constraints are returned.
When a member_of item contains multiple UUIDs, we look up resource
providers that have *any* of those aggregate UUIDs associated with them.
Change-Id: Ib4f1955f06f2159dfb221f3d2bc8ff7bfce71ee2
blueprint: alloc-candidates-member-of
In an earlier patch [0], there were some valid criticisms noted. They
were not critical enough to require holding off on that patch, so they
are being addressed here in a follow-up patch.
[0] I5857e927a830914c96e040936804e322baccc24c
Blueprint: alloc-candidates-member-of
Change-Id: I762dc4a70613056f1bd9ba7bf11c3a4588bdac70
In a new microversion (1.22) expose support for processing
forbidden traits in GET /resource_providers and GET
/allocation_candidates. A forbidden trait is expressed as
part of the required parameter with a "!" prefix:
required=CUSTOM_FAST,!CUSTOM_SLOW
This change uses db and query processing code adjustments
already present in the code but guarded by a flag. If the
currently requested microversion matches 1.22 or beyond
that flag is True, otherwise False.
Reno, api-ref update and api history update are included.
Because this microversion changes the value of an existing
parameter it was unclear how to best express that in the
api-ref. In this case existing parameter references were
annotated.
Partially implements blueprint placement-forbidden-traits
Change-Id: I43e92bc5f97db7a2b09e64c6cb953c07d0561e63
This patch fixes the following items.
* GET /resource_providers
Wrong order of query parameters.
They should be sorted by microversion order.
* POST /resource_providers
A required parameter is defined as optional.
Set it as required.
Change-Id: I66c9608cd6b4a938ca7f8450d4130e942360a9f0
Closes-Bug: #1760520
The call to GET /allocation_candidates now accepts a 'member_of'
parameter, representing one or more aggregate UUIDs. If this parameter
is supplied, the allocation_candidates returned will be limited to those
with resource_providers that belong to at least one of the supplied
aggregates.
Blueprint: alloc-candidates-member-of
Change-Id: I5857e927a830914c96e040936804e322baccc24c
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: I8624e194fe0173531c5aa2119c903e3c68b8c6cd
blueprint: generation-from-create-provider
Placement API microversion 1.19 enhances the payloads for the `GET
/resource_providers/{uuid}/aggregates` response and the `PUT
/resource_providers/{uuid}/aggregates` request and response to be
identical, and to include the ``resource_provider_generation``. As with
other generation-aware APIs, if the ``resource_provider_generation``
specified in the `PUT` request does not match the generation known by
the server, a 409 Conflict error is returned.
Change-Id: I86416e35da1798cdf039b42c9ed7629f0f9c75fc
blueprint: placement-aggregate-generation
Introduce placement microversion 1.18 with a new ?required=<trait list>
query parameter accepted on the GET /resource_providers API. Results
are filtered by providers possessing *all* of the specified traits.
Empty/invalid traits result in 400 errors.
Change-Id: I8191c9a390cb02b2a38a3f1c6e29457435994981
blueprint: traits-on-list-resource-providers
It was pointed out [1] that the semantic difference between how the
`resources` query parameter is handled by GET /resource_providers versus
GET /allocation_candidates is not clear based on the API reference
descriptions, which are identical. This change set clarifies the
wording for both, making it clear that a) allocations are taking into
account; and b) GET /allocation_candidates is working with groups of
providers that must *collectively* satisfy the resource specification.
[1] https://review.openstack.org/#/c/547056/2/specs/rocky/approved/traits-on-list-resource-providers.rst@33
Change-Id: Ia2a4f8f80ec68dd9c95e084c292a2fe2d6ec1b2d
In "List resource providers" API,
a 400 badRequest is missing in API reference.
So add it.
Change-Id: I92fcbd6bc1477dd0fe6554c0ba631b9cb7d6fa53
Closes-Bug: #1750728
JSON body examples of Placement API reference
are in the same directroy where *.inc files exist.
This patch moves JSON body examples to an isolated directory
in order to make it easier to maintain the API reference.
Change-Id: I8fd587100d22bd10dd4b2b2f1b25c5ecc7fc8537
Since the DELETE /resource_providers/{u}/inventories and .../traits APIs
don't have a way to accept generation, they're not "threadsafe" in the
sense of multiple client threads managing traits/inventories for the
same provider. This change adds a note to the documentation for these
APIs to this effect, suggesting the use of PUT with empty
traits/inventories instead.
Change-Id: Icfd79cc1f5a912131845a22b4fe900147b19f934
Closes-Bug: #1746373
The placement API reference documentation for POST /resource_classes [1]
said:
The new class must be a custom resource class, prefixed with CUSTOM_ and
distinct from the _standard_ resource classes.
...where _standard_ was a link to os-traits documentation [2]. Since we
don't have os-resource-classes (yet), this change set removes that
linkitude.
[1] https://developer.openstack.org/api-ref/placement/#create-resource-class
[2] https://docs.openstack.org/os-traits/latest/
Change-Id: I15fbed460598b7d603eca48cbaecf1036906f6c7
Closes-Bug: #1747095
The description of placement resource provider aggregates is mostly
discussing how they aren't nova's concept of host aggregates, but
doesn't give a very simple description of what they are.
This provides a simple description and the canonical example of a
shared storage pool.
Change-Id: I3b7c6404d364c045f19390e86fd1b747baf11f8c
This patch add new query parameter `required` to the
`GET /allocation_candidates` API, which is used to filter candidates
with required traits. The candidate attached traits return in the
provider summary also. Those API changes are added by new microversion.
Also using specific exception TraitNotFound instead of the generic
exception ValueError when invalid traits in the request.
Change-Id: Id821b5b2768dcc698695ba6570c6201e1e9a8233
Implement blueprint add-trait-support-in-allocation-candidates
Takashi NATSUME