diff --git a/releasenotes/notes/allocation-candidates-limit-37fe5c2ce57daf7f.yaml b/releasenotes/notes/allocation-candidates-limit-37fe5c2ce57daf7f.yaml deleted file mode 100644 index 02a904e17..000000000 --- a/releasenotes/notes/allocation-candidates-limit-37fe5c2ce57daf7f.yaml +++ /dev/null @@ -1,11 +0,0 @@ ---- -features: - - | - Add support, in new placement microversion 1.16, for a ``limit`` query - parameter when making a ``GET /allocation_candidates`` request. The - parameter accepts an integer value, `N`, which limits the number of - candidates returned. A new configuration item - ``[placement]/randomize_allocation_candidates``, defaulting to `False`, - controls how the limited results are chosen. If `True`, a random sampling - of the entire result set is taken, otherwise the first N results are - returned. diff --git a/releasenotes/notes/allocation-candidates-traits-1adf079ed0c6563c.yaml b/releasenotes/notes/allocation-candidates-traits-1adf079ed0c6563c.yaml deleted file mode 100644 index eceb9b3ae..000000000 --- a/releasenotes/notes/allocation-candidates-traits-1adf079ed0c6563c.yaml +++ /dev/null @@ -1,10 +0,0 @@ ---- -features: - - | - Add ``required`` query parameter to the ``GET /allocation_candidates`` API - in new placement microversion 1.17. The parameter accepts a list of traits - separated by ``,``, which is used to further limit the list of allocation - requests to resource providers that have the capacity to fulfill the - requested resources AND *collectively* have all of the required traits - associated with them. In the same microversion, the provider summary - includes the traits associated with each provider. diff --git a/releasenotes/notes/allocation_candidates_support_member_of-92f7e1440ed63fe7.yaml b/releasenotes/notes/allocation_candidates_support_member_of-92f7e1440ed63fe7.yaml deleted file mode 100644 index 6ea43e891..000000000 --- a/releasenotes/notes/allocation_candidates_support_member_of-92f7e1440ed63fe7.yaml +++ /dev/null @@ -1,13 +0,0 @@ ---- -features: - - | - Add support, in a new placement microversion 1.21, for the ``member_of`` - query parameter, representing one or more aggregate UUIDs. When supplied, - it will filter the returned allocation candidates to only those - resource_providers that are associated with ("members of") the specified - aggregate(s). This parameter can have a value of either a single aggregate - UUID, or a comma-separated list of aggregate UUIDs. When specifying more - than one aggregate, a resource provider needs to be associated with at - least one of the aggregates in order to be included; it does not have to be - associated with all of them. Because of this, the list of UUIDs must be - prefixed with ``in:`` to represent the logical ``OR`` of the selection. diff --git a/releasenotes/notes/allow-reserved-equal-total-inventory-fe93584dd28c460d.yaml b/releasenotes/notes/allow-reserved-equal-total-inventory-fe93584dd28c460d.yaml deleted file mode 100644 index ecbeee8d4..000000000 --- a/releasenotes/notes/allow-reserved-equal-total-inventory-fe93584dd28c460d.yaml +++ /dev/null @@ -1,6 +0,0 @@ ---- -features: - - | - Introduces new placement API version ``1.26``. Starting with this version - it is allowed to define resource provider inventories with reserved value - equal to total. diff --git a/releasenotes/notes/bp-granular-placement-policy-65722fc6d7cb1359.yaml b/releasenotes/notes/bp-granular-placement-policy-65722fc6d7cb1359.yaml deleted file mode 100644 index 90fc54a9e..000000000 --- a/releasenotes/notes/bp-granular-placement-policy-65722fc6d7cb1359.yaml +++ /dev/null @@ -1,31 +0,0 @@ ---- -features: - - | - It is now possible to configure granular policy rules for placement - REST API operations. - - By default, all operations continue to use the ``role:admin`` check string - so there is no upgrade impact. - - A new configuration option is introduced, ``[placement]/policy_file``, - which is used to configure the location of the placement policy file. - By default, the ``placement-policy.yaml`` file may live alongside the - nova policy file, e.g.: - - * /etc/nova/policy.yaml - * /etc/nova/placement-policy.yaml - - However, if desired, ``[placement]/policy_file`` makes it possible to - package and deploy the placement policy file separately to make the future - split of placement and nova packages easier, e.g.: - - * /etc/placement/policy.yaml - - All placement policy rules are defined in code so by default no extra - configuration is required and the default rules will be used on start of - the placement service. - - For more information about placement policy including a sample file, see - the configuration reference documentation: - - https://docs.openstack.org/nova/latest/configuration/index.html#placement-policy diff --git a/releasenotes/notes/bp-symmetric-allocations-6ff7b270c32dcb7d.yaml b/releasenotes/notes/bp-symmetric-allocations-6ff7b270c32dcb7d.yaml deleted file mode 100644 index f847f9a44..000000000 --- a/releasenotes/notes/bp-symmetric-allocations-6ff7b270c32dcb7d.yaml +++ /dev/null @@ -1,11 +0,0 @@ ---- -features: - - | - The 1.12 version of the placement API changes handling of the `PUT - /allocations/{consumer_uuid}` request to use a dict-based structure for - the JSON request body to make it more aligned with the response body of - `GET /allocations/{consumer_uuid}`. Because `PUT` requires `user_id` - and `project_id` in the request body, these fields are added to the - `GET` response. In addition, the response body for - ``GET /allocation_candidates`` is updated so the allocations in the - ``allocation_requests`` object work with the new `PUT` format. diff --git a/releasenotes/notes/bug-1732000-log-options-6db2cc8c747145ca.yaml b/releasenotes/notes/bug-1732000-log-options-6db2cc8c747145ca.yaml deleted file mode 100644 index e3cbfbeff..000000000 --- a/releasenotes/notes/bug-1732000-log-options-6db2cc8c747145ca.yaml +++ /dev/null @@ -1,7 +0,0 @@ ---- -fixes: - - | - The ``[DEFAULT]/log_options`` configuration option can be used to log - configuration options at DEBUG level when the `placement-api` and/or - `nova-api` services are started under WSGI. The default behavior is to - log options on startup. diff --git a/releasenotes/notes/consumer_generation-f576ac2594b24e2e.yaml b/releasenotes/notes/consumer_generation-f576ac2594b24e2e.yaml deleted file mode 100644 index 3cca2c1d9..000000000 --- a/releasenotes/notes/consumer_generation-f576ac2594b24e2e.yaml +++ /dev/null @@ -1,18 +0,0 @@ ---- -features: - - | - Adds a new ``generation`` column to the consumers table. This value is - incremented every time allocations are made for a consumer. The new - placement microversion 1.28 requires that all ``POST /allocations`` and - ``PUT /allocations/{consumer_uuid}`` requests now include the - ``consumer_generation`` parameter to ensure that if two processes are - allocating resources for the same consumer, the second one to complete - doesn't overwrite the first. If there is a mismatch between the - ``consumer_generation`` in the request and the current value in the - database, the allocation will fail, and a 409 Conflict response will be - returned. The calling process must then get the allocations for that - consumer by calling ``GET /allocations/{consumer}``. That response will now - contain, in addition to the allocations, the current generation value for - that consumer. Depending on the use case, the calling process may error; or - it may wish to combine or replace the existing allocations with the ones it - is trying to post, and re-submit with the current consumer_generation. diff --git a/releasenotes/notes/delete-inventories-placement-api-13582910371308c4.yaml b/releasenotes/notes/delete-inventories-placement-api-13582910371308c4.yaml deleted file mode 100644 index 69d7195e5..000000000 --- a/releasenotes/notes/delete-inventories-placement-api-13582910371308c4.yaml +++ /dev/null @@ -1,18 +0,0 @@ ---- -features: - - | - Supports a new method for deleting all inventory for a - resource provider - - * DELETE /resource-providers/{uuid}/inventories - - Return codes - - * 204 NoContent on success - * 404 NotFound for missing resource provider - * 405 MethodNotAllowed if a microversion is specified that is before - this change (1.5) - * 409 Conflict if inventory in use or if some other request concurrently - updates this resource provider - - Requires OpenStack-API-Version placement 1.5 diff --git a/releasenotes/notes/idempotent-put-resource-class-dc7a267c823b7995.yaml b/releasenotes/notes/idempotent-put-resource-class-dc7a267c823b7995.yaml deleted file mode 100644 index 3892d27f5..000000000 --- a/releasenotes/notes/idempotent-put-resource-class-dc7a267c823b7995.yaml +++ /dev/null @@ -1,10 +0,0 @@ ---- -features: - - | - The 1.7 version of the placement API changes handling of - `PUT /resource_classes/{name}` to be a create or verification of the - resource class with `{name}`. If the resource class is a custom resource - class and does not already exist it will be created and a ``201`` response - code returned. If the class already exists the response code will be - ``204``. This makes it possible to check or create a resource class in one - request. diff --git a/releasenotes/notes/multi-member-of-4f9518a96652c0c6.yaml b/releasenotes/notes/multi-member-of-4f9518a96652c0c6.yaml deleted file mode 100644 index 7bf29cb5e..000000000 --- a/releasenotes/notes/multi-member-of-4f9518a96652c0c6.yaml +++ /dev/null @@ -1,20 +0,0 @@ ---- -features: - - | - A new 1.24 placement API microversion adds the ability to specify multiple - `member_of` query parameters for the `GET /resource_providers` and `GET - allocation_candidates` endpoints. - When multiple `member_of` query parameters are received, the placement - service will return resource providers that match all of the requested - aggregate memberships. The `member_of=in:` format is still - supported and continues to indicate an IN() operation for aggregate - membership. Some examples for using the new functionality: - Get all providers that are associated with BOTH agg1 and agg2: - ?member_of=agg1&member_of=agg2 - Get all providers that are associated with agg1 OR agg2: - ?member_of=in:agg1,agg2 - Get all providers that are associated with agg1 and ANY OF (agg2, agg3): - ?member_of=agg1&member_of=in:agg2,agg3 - Get all providers that are associated with ANY OF (agg1, agg2) AND are also - associated with ANY OF (agg3, agg4): - ?member_of=in:agg1,agg2&member_of=in:agg3,agg4 diff --git a/releasenotes/notes/nested-resource-providers-allocation-candidates-66c1c5b0a3e93513.yaml b/releasenotes/notes/nested-resource-providers-allocation-candidates-66c1c5b0a3e93513.yaml deleted file mode 100644 index 5f26162a4..000000000 --- a/releasenotes/notes/nested-resource-providers-allocation-candidates-66c1c5b0a3e93513.yaml +++ /dev/null @@ -1,11 +0,0 @@ ---- -features: - - | - From microversion 1.29, we support allocation candidates with nested - resource providers. Namely, the following features are added. - 1) ``GET /allocation_candidates`` is aware of nested providers. Namely, - when provider trees are present, ``allocation_requests`` in the response - of ``GET /allocation_candidates`` can include allocations on combinations - of multiple resource providers in the same tree. - 2) ``root_provider_uuid`` and ``parent_provider_uuid`` are added to - ``provider_summaries`` in the response of ``GET /allocation_candidates``. diff --git a/releasenotes/notes/placement-aggregate-generation-9dad79fb0356fcc0.yaml b/releasenotes/notes/placement-aggregate-generation-9dad79fb0356fcc0.yaml deleted file mode 100644 index 3c614e93a..000000000 --- a/releasenotes/notes/placement-aggregate-generation-9dad79fb0356fcc0.yaml +++ /dev/null @@ -1,10 +0,0 @@ ---- -features: - - | - 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. diff --git a/releasenotes/notes/placement-allocation-candidates-1114a843755b93c4.yaml b/releasenotes/notes/placement-allocation-candidates-1114a843755b93c4.yaml deleted file mode 100644 index e7441ea5b..000000000 --- a/releasenotes/notes/placement-allocation-candidates-1114a843755b93c4.yaml +++ /dev/null @@ -1,10 +0,0 @@ ---- -features: - - | - A new 1.10 API microversion is added to the Placement REST API. This - microversion adds support for the GET /allocation_candidates resource - endpoint. This endpoint returns information about possible allocation - requests that callers can make which meet a set of resource constraints - supplied as query string parameters. Also returned is some inventory and - capacity information for the resource providers involved in the allocation - candidates. diff --git a/releasenotes/notes/placement-allocations-link-in-get-resource-providers-0b1d26a264eceb4b.yaml b/releasenotes/notes/placement-allocations-link-in-get-resource-providers-0b1d26a264eceb4b.yaml deleted file mode 100644 index 2bdf8abc6..000000000 --- a/releasenotes/notes/placement-allocations-link-in-get-resource-providers-0b1d26a264eceb4b.yaml +++ /dev/null @@ -1,6 +0,0 @@ ---- -features: - - | - A new 1.11 API microversion is added to the Placement REST API. This adds - the ``resource_providers/{rp_uuid}/allocations`` link to the ``links`` - section of the response from ``GET /resource_providers``. diff --git a/releasenotes/notes/placement-api-endpoint-interface-set-29af8b9400ce7775.yaml b/releasenotes/notes/placement-api-endpoint-interface-set-29af8b9400ce7775.yaml deleted file mode 100644 index 8f80b68ee..000000000 --- a/releasenotes/notes/placement-api-endpoint-interface-set-29af8b9400ce7775.yaml +++ /dev/null @@ -1,9 +0,0 @@ ---- -other: - - The Placement API can be set to connect to a specific - keystone endpoint interface using the ``os_interface`` - option in the ``[placement]`` section inside ``nova.conf``. - This value is not required but can be used if a non-default - endpoint interface is desired for connecting to the Placement - service. By default, keystoneauth will connect to the "public" - endpoint. diff --git a/releasenotes/notes/placement-api-member-of-d8a08d0d0c5700d7.yaml b/releasenotes/notes/placement-api-member-of-d8a08d0d0c5700d7.yaml deleted file mode 100644 index 7f1045ffc..000000000 --- a/releasenotes/notes/placement-api-member-of-d8a08d0d0c5700d7.yaml +++ /dev/null @@ -1,14 +0,0 @@ ---- -features: - - | - A new Placement API microversion 1.3 is added with support for filtering - the list of resource providers to include only those resource providers - which are members of any of the aggregates listed by uuid in the `member_of` - query parameter. The parameter is used when making a - `GET /resource_providers` request. The value of the parameter uses the - `in:` syntax to provide a list of aggregate uuids as follows:: - - /resource_providers?member_of=in:09c931b0-c0d7-4e80-8e01-9e6511db8259,f8ab4fa2-804f-402e-b675-7918bd04b173 - - If other filtering query parameters are present, the results are a boolean - AND of all the filters. diff --git a/releasenotes/notes/placement-cors-c7a83e8c63787736.yaml b/releasenotes/notes/placement-cors-c7a83e8c63787736.yaml deleted file mode 100644 index 6ea9af445..000000000 --- a/releasenotes/notes/placement-cors-c7a83e8c63787736.yaml +++ /dev/null @@ -1,9 +0,0 @@ ---- -features: - - | - The placement API service can now be configured to support - `CORS `_. - If a `cors` configuration group is present in the service's configuration - file (currently `nova.conf`), with `allowed_origin` configured, the values - within will be used to configure the middleware. If `cors.allowed_origin` - is not set, the middleware will not be used. diff --git a/releasenotes/notes/placement-database-2e087f379273535d.yaml b/releasenotes/notes/placement-database-2e087f379273535d.yaml deleted file mode 100644 index 41798f6fd..000000000 --- a/releasenotes/notes/placement-database-2e087f379273535d.yaml +++ /dev/null @@ -1,24 +0,0 @@ ---- -features: - - | - An optional configuration group ``placement_database`` can be used in - nova.conf to configure a separate database for use with the placement - API. - - If ``placement_database.connection`` has a value then the - ``placement_database`` configuration group will be used to configure a - separate placement database, including using ``connection`` to identify the - target database. That database will have a schema that is a replica of all - the tables used in the API database. The new database schema will be - created and synchronized when the ``nova-manage api_db sync`` command is - run. - - When the ``placement_database.connection`` setting is omitted the existing - settings for the ``api_database`` will be used for hosting placement data. - - Setting ``placement_database.connection`` and calling - ``nova-manage api_db sync`` will only create tables. No data will be - migrated. In an existing OpenStack deployment, if there is existing - placement data in the ``nova_api`` database this will not be copied. It is - up to the deployment to manually replicate that data in a fashion that - works best for the environment. diff --git a/releasenotes/notes/placement-error-code-fcbbf5d45560984e.yaml b/releasenotes/notes/placement-error-code-fcbbf5d45560984e.yaml deleted file mode 100644 index 9d114f4ed..000000000 --- a/releasenotes/notes/placement-error-code-fcbbf5d45560984e.yaml +++ /dev/null @@ -1,9 +0,0 @@ ---- -features: - - | - In microversion 1.23 of the placement service, JSON formatted error - responses gain a new attribute, ``code``, with a value that identifies the - type of this error. This can be used to distinguish errors that are - different but use the same HTTP status code. Any error response which does - not specifically define a code will have the code - ``placement.undefined_code``. diff --git a/releasenotes/notes/placement-forbidden-traits-ace037856aa29a09.yaml b/releasenotes/notes/placement-forbidden-traits-ace037856aa29a09.yaml deleted file mode 100644 index b5c0b744d..000000000 --- a/releasenotes/notes/placement-forbidden-traits-ace037856aa29a09.yaml +++ /dev/null @@ -1,9 +0,0 @@ ---- -features: - - | - Placement microversion '1.22' adds support for expressing traits which are - forbidden when filtering ``GET /resource_providers`` or ``GET - /allocation_candidates``. A forbidden trait is a properly formatted trait - in the existing ``required`` parameter, prefixed by a ``!``. For example - ``required=!STORAGE_DISK_SSD`` asks that the results not include any - resource providers that provide solid state disk. diff --git a/releasenotes/notes/placement-generation-from-create-provider-203a0ac1ebfe64d9.yaml b/releasenotes/notes/placement-generation-from-create-provider-203a0ac1ebfe64d9.yaml deleted file mode 100644 index 522f6d295..000000000 --- a/releasenotes/notes/placement-generation-from-create-provider-203a0ac1ebfe64d9.yaml +++ /dev/null @@ -1,9 +0,0 @@ ---- -features: - - | - In placement API microversion 1.20, a successful `POST /resource_providers` - returns 200 with a payload representing the newly-created resource - provider. The format is the same format as the result of the corresponding - ``GET /resource_providers/{uuid}`` call. This is to allow the caller to - glean automatically-set fields, such as UUID and generation, without a - subsequent GET. diff --git a/releasenotes/notes/placement-granular-resource-requests-944f9b73f306429f.yaml b/releasenotes/notes/placement-granular-resource-requests-944f9b73f306429f.yaml deleted file mode 100644 index af9ac2444..000000000 --- a/releasenotes/notes/placement-granular-resource-requests-944f9b73f306429f.yaml +++ /dev/null @@ -1,31 +0,0 @@ ---- -features: - - | - In version 1.25 of the Placement API, ``GET /allocation_candidates`` is - enhanced to accept numbered groupings of resource, required/forbidden - trait, and aggregate association requests. A ``resources`` query parameter - key with a positive integer suffix (e.g. ``resources42``) will be logically - associated with ``required`` and/or ``member_of`` query parameter keys with - the same suffix (e.g. ``required42``, ``member_of42``). The resources, - required/forbidden traits, and aggregate associations in that group will be - satisfied by the same resource provider in the response. When more than one - numbered grouping is supplied, the ``group_policy`` query parameter is - required to indicate how the groups should interact. With - ``group_policy=none``, separate groupings - numbered or unnumbered - may or - may not be satisfied by the same provider. With ``group_policy=isolate``, - numbered groups are guaranteed to be satisfied by *different* providers - - though there may still be overlap with the unnumbered group. In all cases, - each ``allocation_request`` will be satisfied by providers in a single - non-sharing provider tree and/or sharing providers associated via aggregate - with any of the providers in that tree. - - The ``required`` and ``member_of`` query parameters for a given group are - optional. That is, you may specify ``resources42=XXX`` without a - corresponding ``required42=YYY`` or ``member_of42=ZZZ``. However, the - reverse (specifying ``required42=YYY`` or ``member_of42=ZZZ`` without - ``resources42=XXX``) will result in an error. - - The semantic of the (unnumbered) ``resources``, ``required``, and - ``member_of`` query parameters is unchanged: the resources, traits, and - aggregate associations specified thereby may be satisfied by any provider - in the same non-sharing tree or associated via the specified aggregate(s). diff --git a/releasenotes/notes/placement-incomplete-consumer-configuration-b775dac1bcd34f9d.yaml b/releasenotes/notes/placement-incomplete-consumer-configuration-b775dac1bcd34f9d.yaml deleted file mode 100644 index ec45ad200..000000000 --- a/releasenotes/notes/placement-incomplete-consumer-configuration-b775dac1bcd34f9d.yaml +++ /dev/null @@ -1,11 +0,0 @@ ---- -features: - - | - Prior to microversion 1.8 of the placement API, one could create - allocations and not supply a project or user ID for the consumer of the - allocated resources. While this is no longer allowed after placement API - 1.8, older allocations exist and we now ensure that a consumer record is - created for these older allocations. Use the two new CONF options - ``CONF.placement.incomplete_consumer_project_id`` and - ``CONF.placement.incomplete_consumer_user_id`` to control the project and - user identifiers that are written for these incomplete consumer records. diff --git a/releasenotes/notes/placement-last-modified-cf43aece4c54fc97.yaml b/releasenotes/notes/placement-last-modified-cf43aece4c54fc97.yaml deleted file mode 100644 index 284c9ee55..000000000 --- a/releasenotes/notes/placement-last-modified-cf43aece4c54fc97.yaml +++ /dev/null @@ -1,10 +0,0 @@ ---- -features: - - | - Throughout the Placement API, in microversion 1.15, 'last-modified' headers - have been added to GET responses and those PUT and POST responses that have - bodies. The value is either the actual last modified time of the most - recently modified associated database entity or the current time if there - is no direct mapping to the database. In addition, - 'cache-control: no-cache' headers are added where the 'last-modified' - header has been added to prevent inadvertent caching of resources. diff --git a/releasenotes/notes/placement-required-traits-on-list-resource-providers-fab11cdb36cd3502.yaml b/releasenotes/notes/placement-required-traits-on-list-resource-providers-fab11cdb36cd3502.yaml deleted file mode 100644 index 1fa3ecd37..000000000 --- a/releasenotes/notes/placement-required-traits-on-list-resource-providers-fab11cdb36cd3502.yaml +++ /dev/null @@ -1,12 +0,0 @@ ---- -features: - - | - Placement API microversion 1.18 adds support for the `required` query - parameter to the `GET /resource_providers` API. It accepts a - comma-separated list of string trait names. When specified, the API - results will be filtered to include only resource providers marked with - all the specified traits. This is in addition to (logical AND) any - filtering based on other query parameters. - - Trait names which are empty, do not exist, or are otherwise invalid will - result in a 400 error. diff --git a/releasenotes/notes/placement-rest-api-filter-providers-by-resources-0ab51c9766fe654f.yaml b/releasenotes/notes/placement-rest-api-filter-providers-by-resources-0ab51c9766fe654f.yaml deleted file mode 100644 index 86633310e..000000000 --- a/releasenotes/notes/placement-rest-api-filter-providers-by-resources-0ab51c9766fe654f.yaml +++ /dev/null @@ -1,19 +0,0 @@ ---- -features: - - | - A new Placement API microversion 1.4 is added. Users may now query the - Placement REST API for resource providers that have the ability to meet a - set of requested resource amounts. The `GET /resource_providers` API call - can have a "resources" query string parameter supplied that indicates the - requested amounts of various resources that a provider must have the - capacity to serve. The "resources" query string parameter takes the form: - - ``?resources=$RESOURCE_CLASS_NAME:$AMOUNT,$RESOURCE_CLASS_NAME:$AMOUNT`` - - For instance, if the user wishes to see resource providers that can service - a request for 2 vCPUs, 1024 MB of RAM and 50 GB of disk space, the user can - issue a request of:: - - ``GET /resource_providers?resources=VCPU:2,MEMORY_MB:1024,DISK_GB:50`` - - The placement API is only available to admin users. diff --git a/releasenotes/notes/placement-rest-api-nested-resource-providers-552a923a96d7adca.yaml b/releasenotes/notes/placement-rest-api-nested-resource-providers-552a923a96d7adca.yaml deleted file mode 100644 index 548c4c93d..000000000 --- a/releasenotes/notes/placement-rest-api-nested-resource-providers-552a923a96d7adca.yaml +++ /dev/null @@ -1,13 +0,0 @@ ---- -features: - - New placement REST API microversion 1.14 is added to support nested - resource providers. Users of the placement REST API can now pass a - ``in_tree=`` parameter to the ``GET /resource_providers`` REST API - call. This will trigger the placement service to return all resource - provider records within the "provider tree" of the resource provider with - the supplied UUID value. The resource provider representation now includes - a ``parent_provider_uuid`` value that indicates the UUID of the immediate - parent resource provider, or ``null`` if the provider has no parent. For - convenience, the resource provider resource also contains a - ``root_provider_uuid`` field that is populated with the UUID of the - top-most resource provider in the provider tree. diff --git a/releasenotes/notes/placement-rest-custom-resource-classes-a3f2175772983b0a.yaml b/releasenotes/notes/placement-rest-custom-resource-classes-a3f2175772983b0a.yaml deleted file mode 100644 index 8918b3067..000000000 --- a/releasenotes/notes/placement-rest-custom-resource-classes-a3f2175772983b0a.yaml +++ /dev/null @@ -1,10 +0,0 @@ ---- -features: - - | - A new administrator-only resource endpoint was added to the OpenStack - Placement REST API for managing custom resource classes. Custom resource - classes are specific to a deployment and represent types of quantitative - resources that are not interoperable between OpenStack clouds. See the - `Placement REST API Version History`_ documentation for usage details. - - .. _Placement REST API Version History: http://docs.openstack.org/developer/nova/placement.html#id2 diff --git a/releasenotes/notes/placement-return-all-resources-bfc7e3f8b5151e28.yaml b/releasenotes/notes/placement-return-all-resources-bfc7e3f8b5151e28.yaml deleted file mode 100644 index ba3bb32af..000000000 --- a/releasenotes/notes/placement-return-all-resources-bfc7e3f8b5151e28.yaml +++ /dev/null @@ -1,9 +0,0 @@ ---- -features: - - | - From microversion 1.27, the ``provider_summaries`` field in the - response of the ``GET /allocation_candidates`` API includes all - the resource class inventories, while it had only requested - resource class inventories with older microversions. - Now callers can use this additional inventory information in - making further sorting or filtering decisions. diff --git a/releasenotes/notes/placement-traits-api-efa17d46ea1b616b.yaml b/releasenotes/notes/placement-traits-api-efa17d46ea1b616b.yaml deleted file mode 100644 index 484be3f51..000000000 --- a/releasenotes/notes/placement-traits-api-efa17d46ea1b616b.yaml +++ /dev/null @@ -1,15 +0,0 @@ ---- -features: - - | - Traits are added to the placement with Microversion 1.6. - - * GET /traits: Returns all resource classes. - * PUT /traits/{name}: To insert a single custom trait. - * GET /traits/{name}: To check if a trait name exists. - * DELETE /traits/{name}: To delete the specified trait. - * GET /resource_providers/{uuid}/traits: a list of traits associated - with a specific resource provider - * PUT /resource_providers/{uuid}/traits: Set all the traits for a - specific resource provider - * DELETE /resource_providers/{uuid}/traits: Remove any existing trait - associations for a specific resource provider diff --git a/releasenotes/notes/post-allocations-427581fa41671820.yaml b/releasenotes/notes/post-allocations-427581fa41671820.yaml deleted file mode 100644 index 80a9115d4..000000000 --- a/releasenotes/notes/post-allocations-427581fa41671820.yaml +++ /dev/null @@ -1,6 +0,0 @@ ---- -features: - - | - Microversion 1.13 of the Placement API gives the ability to set or clear - allocations for more than one consumer uuid with a request to - ``POST /allocations``.