A set of AllocationRequest objects is extended in _merge_candidates,
controlled by the hash of the AllocationRequest, which is based on
a list of AllocationRequestResource objects.
It turns out that this hash can be different depending on the ordering
of the members of the list, with different behaviors in Python 2 and 3.
Therefore, a stable sort is needed to ensure the stability of the hash.
It's quite likely that a sort could have been done elsewhere, but there
are at least two places where resource_requests are added, with
different attributes available for sorting, so this contained
implementation was done instead.
Tests are added that confirms the expected behavior.
Note that the expected behavior will change when we add suffix
mappings to allocation requests. Whereas now
'test_nested_result_count_isolate' gets winnowed to 2 results because
the following are treated as duplicates
[('cn1', orc.VCPU, 2),
('cn1_numa0_pf0', orc.SRIOV_NET_VF, 1),
('cn1_numa1_pf1', orc.SRIOV_NET_VF, 1)],
[('cn1', orc.VCPU, 2),
('cn1_numa0_pf0', orc.SRIOV_NET_VF, 1),
('cn1_numa1_pf1', orc.SRIOV_NET_VF, 1)],
they are in fact slightly different: one set has pf0 satisfying group
_NET1 and pf1 _NET2, the other vice versa. With mappings available
we presumably want to expose this difference, resulting in more...
results.
An interesting note: The original bug report was that python 2.7 was
varying across 3 values, sometimes right, but mostly wrong and 3.7
was always right. Turns out that 3.7 was consistently wrong, and 2.7
was mostly right, but not always.
Change-Id: I4fce243659d5c429dc3d48f07888e38bd0aed5d4
Story: 2005822
Task: 33579
81937773f5