Trim the release notes to just stein/master

This removes all the releasenotes related to changes already released
with nova in rocky and prior. They were carried over into placement
as we weren't sure how we were going to manage release notes. In
a meeting it was decided that we would start the release notes fresh
with "since-extraction".

Therefore this change removes all the releasenotes that are already
present in nova, keeping anything new.

The index.rst file is already set to say "look at nova" for older
release notes.

Change-Id: If9255212acf21ed69abbed0601c783ad01133f72
This commit is contained in:
Chris Dent 2019-01-16 19:08:50 +00:00
parent 0e97f2b9b9
commit fca086e654
32 changed files with 0 additions and 411 deletions

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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

View File

@ -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.

View File

@ -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:<agg uuids>` 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

View File

@ -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``.

View File

@ -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.

View File

@ -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.

View File

@ -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``.

View File

@ -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.

View File

@ -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.

View File

@ -1,9 +0,0 @@
---
features:
- |
The placement API service can now be configured to support
`CORS <http://docs.openstack.org/developer/oslo.middleware/cors.html>`_.
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.

View File

@ -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.

View File

@ -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``.

View File

@ -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.

View File

@ -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.

View File

@ -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).

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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=<UUID>`` 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.

View File

@ -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

View File

@ -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.

View File

@ -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

View File

@ -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``.