14 Commits

Author SHA1 Message Date
Tetsuro Nakamura
efaa36443f Follow up fix for same_subtree documentation
This patch fixes incorrect usages of fixed articles changing them to
indefinite articles in same_subtree documentation.

Change-Id: I6ba2e2f13400b4c2ae9a44cad7a1fc9a9e39b41d
Story: 2005575
Task: 30784
2019-07-09 10:23:54 +00:00
Tetsuro Nakamura
8395e3f099 Support same_subtree queryparam
A new same_subtree query parameter will be accepted. The value is
a comma-separated list of request group suffix strings $S. Each must
exactly match a suffix on a granular group somewhere else in the
request. Importantly, the identified request groups need not have
a resources$S.

If this is provided, at least one of the resource providers satisfying
the specified request group must be an ancestor of the rest.

The same_subtree query parameter can be repeated and each repeat group
is treated independently.

Co-Authored-By: Chris Dent <cdent@anticdent.org>
Change-Id: I7fdeac24606359d37f1a7405d22c5797840e1a9e
Story: 2005575
Task: 30784
2019-07-09 07:21:53 +00:00
Eric Fried
b733786a0a Microversion 1.35: root_required
Microversion 1.35_ adds support for the ``root_required`` query
parameter to the ``GET /allocation_candidates`` API. It accepts a
comma-delimited list of trait names, each optionally prefixed with ``!``
to indicate a forbidden trait, in the same format as the ``required``
query parameter. This restricts allocation requests in the response to
only those whose (non-sharing) tree's root resource provider satisfies
the specified trait requirements.

This is to support use cases like, "Land my VM on a host that is capable
of multi-attach," or, "Reserve my Windows-licensed hosts for special
use."

Story: #2005575
Task: #33753
Change-Id: I76cad83248920fa71da122711f1f763c4ebdb1ba
2019-06-20 17:30:35 -05:00
Chris Dent
d38844e390 Implement allocation candidate mappings
In microversion 1.34 add a 'mappings' key to each allocation
request. Its value is dict keyed by resource group suffixes
with values of a list of resource providers satisfying that
group.

To preserve symmetry, the mappings key may be sent back when
writing allocations so the schema for POST and PUT allocations
and POST /reshaper are updated.

api history, api-ref and reno are added

Change-Id: Ie78ed7e050416d4ccb62697ba608131038bb4303
Story: 2005575
Task: 33536
2019-06-12 21:19:14 +00:00
Chris Dent
fb0f6f2608 Allow [a-zA-Z0-9_-]{1,64} for request group suffix
Add a 1.33 microversion to move from numeric suffixes to string
suffixes that can be 64 chars longs made from '-', '_', and
mixed-case alphanumeric. The format is shared between schema
and RequestGroup parsing.

Docs, api-ref, api history and microversion upper limit are updated
to indicate the new form in the new microversion.

A release note is added.

Story: 2005575
Task: 30781
Change-Id: Ia44b0922d151695d406883262e891bd932536f38
2019-05-21 11:07:38 +01:00
Zuul
2c71b9fe5a Merge "Negative member_of query with microversion 1.32" 2019-04-03 19:59:05 +00:00
Takashi NATSUME
a427641759 Fix a broken link in a release note
Fix a broken link for microversion 1.31 in the stein prelude
release note(*).

*: https://docs.openstack.org/releasenotes/placement/stein.html#prelude

Change-Id: I06cfbc6f2cc3c231e77a4035e830b157f4001a05
Story: 2005337
Task: 30277
2019-04-02 10:52:46 +09:00
Tetsuro Nakamura
0a3dcadb0a Negative member_of query with microversion 1.32
This patch adds microversion 1.32 supporting the forbidden aggregate
expression within existing ``member_of`` queryparam both in
``GET /resource_providers`` and in ``GET /allocation_candidates``.
Forbidden aggregates are prefixed with a ``!``.

We do NOT support ``!`` within the ``in:`` list:

  ?member_of=in:<agg1>,<agg2>,!<agg3>

but we support ``!in:`` prefix:

  ?member_of=!in:<agg1>,<agg2>,<agg3>

which is equivalent to:

  ?member_of=!<agg1>&member_of=!<agg2>&member_of=!<agg3>

where candidate resource providers must not be in agg1, agg2, or agg3.

Change-Id: Ibba7981744c71ab5d4d0ee5d5a40709c6a5c6b5e
Story: 2005297
Task: 30183
2019-03-29 05:14:27 +00:00
Stephen Finucane
083451cd77 Group API versions by release
We have the 'versionadded' directives, but the table of contents is
still a mess. This makes things a little more grokable, IMO.

Change-Id: I6a40e1aa38bc129361fc3db1c6404ce5e8aab625
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
2019-03-20 16:43:11 +00:00
Matt Riedemann
9de5da48a3 Stop yelling the 1.11 and 1.25 microversion history at people
The double back-tick formatting in a title makes the title extra
loud in the docs so just drop that formatting.

Note we don't do that same kind of formatting in other
titles like 1.20 and 1.31 so I'm not breaking with precedent
or something we have to get all knifey about.

Change-Id: I5224776133afa6d9855c535af68f8d73575bad9b
2019-03-06 14:25:49 +00:00
Tetsuro Nakamura
ce10de2a29 in_tree[N] alloc_cands with microversion 1.31
This patch adds microversion 1.31 supporting the `in_tree`/`in_tree<N>`
query parameters to the `GET /allocation_candidates` API. It accepts a
UUID for a resource provider. If this parameter is provided, the only
resource providers returned will be those with the same tree with the
given resource provider.

Change-Id: I24d333d1437168f27aaaac6d894a18271cb6ab91
Blueprint: alloc-candidates-in-tree
2019-02-25 13:00:30 -06:00
Takashi NATSUME
b461f6a207 Fix a format of the API version history doc
TrivialFix
Change-Id: I4f68be3eef11240be6e759dc2b0a945735e09c4e
2018-12-10 04:31:07 +00:00
Yikun Jiang
cddcac6869 Refresh maximum version info in rest history doc
The versionadded info is added in [1], but 1.30 didn't add
this, so we add it in this patch, and also refresh the
"Maximum in Rocky" info.

[1] https://review.openstack.org/#/c/589392/

Change-Id: I52898c27c7b1161fca3820e65cd250818a19f570
2018-09-10 09:57:20 +08:00
EdLeafe
fb7c190990 Move the placement code to the base
While in Nova, placement code was relegated to the
'nova/api/openstack/placement/' directory. This commit moves that
directory to the base of the repo, and removes the unnecesary
directories.

Change-Id: I023f525d064374283456c77edb6ac7b3d0cf0b0c
2018-09-04 10:31:23 -05:00