Change-Id: I78739a19bf4fa930bdbdb383bb80af64ad21228a

Update the URL to the upper-constraints file to point to the redirect
rule on releases.openstack.org so that anyone working on this branch
will switch to the correct upper-constraints list automatically when
the requirements repository branches.

Until the requirements repository has as stable/2024.1 branch, tests will
continue to use the upper-constraints list on master.

Change-Id: If10c0e7af891a61fb56dfdcbf2de129c085f0350

When a root provider has multiple similar child RPs, i.e. we have a wide
but symmetric tree, and the allocation
candidate request asks for resources in multiple request groups the
number of possible allocation candidates grows rapidly.

* 1 root, 8 child RPs with 1 unit of resource each
  a_c requests 6 groups with 1 unit of resource each
  => 8*7*6*5*4*3=20160 possible candidates

* 1 root, 8 child RPs with 6 unit of resources each
  a_c requests 6 groups with 6 unit of resources each
  => 8^6=262144 possible candidates

Placement generates these candidates fully before applying the limit
parameter provided in the query to be able do a random sampling if
[placement]randomize_allocation_candidates is True.

Placement takes excessive time and memory to generates these amount of
allocation candidates.

To avoid request timeout or out of memory events this patch introduces a
new [placement]max_allocation_candidates config option that is applied
not after but *during* the candidate generation loop. So this new option
acts as a global safety limit.

The new config option is defaulted to -1, meaning no limit, to keep the
legacy behavior, but we suggest to tune that config in environments with
wide symmetric trees.

Placement generates the candidates with a depth first approach,
gathering all candidates for a root before moving to the next root. If
the new global limit is applied and hit then it is possible that the
returned candidates are from a limited set of root providers. This issue
will be handled by a subsequent patch allowing to select from
depth-first or breadth-first (round-robin) candidate generation
strategy.

Related-Bug: #2070257
Change-Id: I5475c66fa35958b3dc72c3bab7a7edbdf6c89ce6
(cherry picked from commit 9351241)
(cherry picked from commit f276fc2)

This is a pure refactor to pull out the logic of assembling an
allocation candidate.

The _get_areq_list_generators returns a set of
generators, one per root (anchoring) provider, that can generate all the
viable candidates for that root by applying a product on the solutions
for each request groups.

The _generate_areq_lists implements the strategy of consuming these
generators. The current behavior is that placement consumes the
generator for the first root fully before moving to the next
(depth-first).

A later patch will change _generate_areq_lists to be able to apply
different strategies, like round-robin easily.

Related-Bug: #2070257
Change-Id: I4f8c8491d21426310a82df7186b7689b2dad253e
(cherry picked from commit 04718d6)
(cherry picked from commit 1b0a927)

The previous patch introduced [placement]max_allocation_candidates
config option to limit the number of candidates generated for a single
query.

If the number of generated allocation candidates are limited by that
config option then it is possible to get candidates from a limited set of
root providers (computes, anchoring providers) as placement uses a
depth-first strategy, generating all candidates from the first root
before considering the next one.

To avoid unbalanced results this patch introduces a new config option
[placement]allocation_candidates_generation_strategy with the possible
values:
* depth-first, the original strategy that generates all candidate from
  the first root before moving to the next. This is will be the default
  strategy for backward compatibility
* breadth-first, a new possible strategy that generates candidates from
  available roots in a round-robin fashion, one candidate from each
  root before taking the second candidate from the first root.

Closes-Bug: #2070257
Change-Id: Ib7a140374bc91cc9ab597d0923b0623f618ec32c
(cherry picked from commit f20e13f)
(cherry picked from commit 828b255)

Change-Id: Iba5b03379dfb439b8ae49445049f6aad6b6ce4a5
Signed-off-by: OpenStack Release Bot <infra-root@openstack.org>
Generated-By: openstack/project-config:roles/copy-release-tools-scripts/files/release-tools/functions