Spec: Support filtering by forbidden aggregates 2
This series reproposes the forbidden aggregates spec to placement train directory copying it from nova stein directory. Two changes were made. 1. Procedural change. - The reference URL is changed from launchpad to storyboard. - The history section is added. - The file is renamed to have the prefix of the story id 2. Essential change - The behavior of the API when an agg UUID is found on both the positive and negative sides of the request is documented in the 'REST API impact' section. This patch contains the essential change. Change-Id: Ie67560dbd61ecdc0ad2fe98e9ca9df554edbb1de Story: 2005297 Task: 30183
This commit is contained in:
parent
4baa6cb6d7
commit
bbc2af0b2a
|
@ -170,6 +170,22 @@ A new microversion will be created which will update the validation for the
|
|||
as a prefix to the ``in:`` prefix to express that the prefixed aggregate (or
|
||||
the aggregates) is to be excluded from the results.
|
||||
|
||||
We do not return 400 if an agg UUID is found on both the positive and negative
|
||||
sides of the request. For example::
|
||||
|
||||
&member_of=in:<agg1>,<agg2>&member_of=!<agg2>
|
||||
|
||||
The first member_of would return all resource_providers in either agg1 or agg2,
|
||||
while the second member_of would eliminate those in agg2. The result will be a
|
||||
200 containing just those resource_providers in agg1. Likewise, we do not
|
||||
return 400 for cases like::
|
||||
|
||||
&member_of=<agg1>&member_of=!<agg1>
|
||||
|
||||
As in the previous example, we return 200 with empty results, since this is a
|
||||
syntactically valid request, even though a resource provider cannot be both
|
||||
inside and outside of agg1 at the same time.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
|
|
Loading…
Reference in New Issue