openstack/placement
Code Issues Proposed changes

Recreate: incorrect mappings with group_policy=none

Browse Source 
Adds a gabbi test demonstrating the bug in the associated story:

GET /allocation_candidates
with group_policy=none
and two request groups
which consolidate to land on the same provider

In this case, the mappings should show two entries: one from each
request group to the (same) provider.

However, the test demonstrates that only one mapping is returned. (I
think it's arbitrary which request group will be represented, so the
test only asserts that the size of the mappings dict is one instead of
two.)

Story: #2006068
Task: #34786

Change-Id: I0b12a8ac80e42c605cfd26a3adc1312dedaa3f99
This commit is contained in:
Eric Fried
2019-06-29 12:28:42 -05:00
committed by Tetsuro Nakamura
parent 62d6561795
commit 7cadf3e82a
3 changed files with 34 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
placement/objects/allocation_candidate.py
View File

@@ -806,10 +806,14 @@ def _merge_candidates(candidates, rw_ctx):
# ]
# to this:
# areq_combined(arrX, arrY, arrZ, arrM, arrN, arrQ)
# Note that this discards the information telling us which
# RequestGroup led to which piece of the final AllocationRequest.
# We needed that to be present for the previous filter; we need it
# to be *absent* for the next one (and for the final output).
# Note that the information telling us which RequestGroup led to
# which piece of the AllocationRequest has been lost from the outer
# layer of the data structure (the key of areq_lists_by_suffix).
# => We needed that to be present for the previous filter; we need
# it to be *absent* for the next one.
# => However, it still exists embedded in each
# AllocationRequestResource. That's needed to construct the
# mappings for the output.
areq = _consolidate_allocation_requests(areq_list)
# Since we sourced this AllocationRequest from multiple
# *independent* queries, it's possible that the combined result

2
placement/tests/functional/fixtures/gabbits.py
View File

@@ -402,7 +402,7 @@ class NUMANetworkFixture(APIFixture):
|FPGA:1 | |VGPU:8 | |FPGA:1 | |FPGA:1 | | |
+-------+ +-------+ +-------+ +-------+ | +----+------+
+-----+------+ |br_int |
| | |PHYSNET1 |
| | |PHYSNET0 |
+------+-----++-----+------+|BW_EGR:1000|
|esn1 ||esn2 |+-----------+
|PHYSNET1 ||PHYSNET2 |

26
placement/tests/functional/gabbits/allocation-candidates-mappings-numa.yaml
View File

@@ -86,7 +86,31 @@ tests:
$.allocation_requests[0].mappings._NET1[0]: $ENVIRON['ESN1_UUID']
$.allocation_requests[0].mappings._NET2[0]: $ENVIRON['ESN2_UUID']
# Confirm that a resource provider which providers two different classes
- name: non isolated shows both request groups for the request that combines the resources
GET: /allocation_candidates
query_parameters:
# Two chunks of bandwidth on the same network. We pick PHYSNET1 because
# only one provider with bandwidth resource has that trait (ESN1). This,
# with group_policy=none, forces the resources to be consolidated onto
# that one provider. We need to show that the mappings accurately reflect
# both request groups.
resources_BWA: NET_BW_EGR_KILOBIT_PER_SEC:10
required_BWA: CUSTOM_PHYSNET1
resources_BWB: NET_BW_EGR_KILOBIT_PER_SEC:20
required_BWB: CUSTOM_PHYSNET1
group_policy: none
response_json_paths:
$.allocation_requests.`len`: 1
$.provider_summaries.`len`: 12
# BUG! https://storyboard.openstack.org/#!/story/2006068
# We should get a mapping from each request group to ESN1:
# $.allocation_requests[0].mappings:
# _BWA: ["$ENVIRON['ESN1_UUID']"]
# _BWB: ["$ENVIRON['ESN1_UUID']"]
# But we instead get only one of them. (Which one is arbitrary, I think.)
$.allocation_requests[0].mappings.`len`: 1
# Confirm that a resource provider which provides two different classes
# of inventory only shows up in a mapping for any suffix once.
- name: granular two resources on one suffix
GET: /allocation_candidates