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
When placement picks up allocation candidates, the aggregates of
nested providers were assumed as the same as root providers. This
means that the `GET /allocation_candidates API` ignored the
aggregates on the nested providers. This could result in the lack
of allocation candidates when an aggregate is on a nested provider
but the aggregate is not on its root provider and the aggregate is
specified in the API by the `member_of` query parameter.
This patch fixes the bug changing it to consider the aggregates
not only on root rps but also on the nested rp itself and adds
a release note for this.
The document which explains the whole constraint of `member_of`
and other query parameters with nested providers, will be submitted
in a follow up patch.
Change-Id: I9a11a577174f85a1b47a9e895bb25cadd90bd2ea
Closes-Bug: #1792503
When placement picks up allocation candidates, the aggregates of
nested providers are assumed as the same as root providers. This
means it ignores the aggregates of the nested provider itself.
This could result in the lack of allocation candidates when an
aggregate on a nested provider but not on the root has been
specified in the `member_of` query parameter.
This patch adds test cases for the bug. The fix is done in a
follow up.
Related-Bug: #1792503
Change-Id: Ic532bc231e89eaec4cb5ad01d27bbe840b01a5f7
Eric Fried