aecd0f3497
In testing with the nested-perfload topology containing 7000 providers, _merge_candidates had been returning 21000 ProviderSummary objects which were not trimmed until serialization processing in handlers/allocation_candidate.py. That situation has been present at least since when we added same_subtree [1] so is not simply because of the addition of rw_ctx.summaries_by_id [2]. Teasing out fixing this exposed a lot of opportunities for shrinking the amount of data being inspected and processed. In no particular order the changes are: * Return set() from _alloc_candidates_single_provider and _alloc_candidates_multiple_providers instead of list. It doesn't need to be a list and the cast to list costs. * Because we have rw_ctx.summaries_by_id we don't need to return summaries from _get_by_one_request, they're in the rw_ctx. * The candidates provided to _merge_candidates is no longer a dict of tuples of allocatation requests and summaries (_all_ the summaries). It's just a dict of allocation requests. * At the end of _merge_candidates we need to winnow the contents of rw_ctx.summaries_by_id to only those that still matter. [1] I7fdeac24606359d37f1a7405d22c5797840e1a9e [2] I43ae1118421366336b4e96738c2981e07caebec8 Change-Id: Ibccaed40f1eac9c244cf70654f6be1d72f7a6054 |
||
|---|---|---|
| api-ref | ||
| doc | ||
| etc/placement | ||
| gate | ||
| placement | ||
| placement_db_tools | ||
| playbooks | ||
| releasenotes | ||
| tools | ||
| .coveragerc | ||
| .gitignore | ||
| .gitreview | ||
| .stestr.conf | ||
| .zuul.yaml | ||
| babel.cfg | ||
| bindep.txt | ||
| CONTRIBUTING.rst | ||
| LICENSE | ||
| lower-constraints.txt | ||
| README.rst | ||
| requirements.txt | ||
| setup.cfg | ||
| setup.py | ||
| test-requirements.txt | ||
| tox.ini | ||
If you are viewing this README on GitHub, please be aware that placement development happens on OpenStack git and OpenStack gerrit.
Team and repository tags
OpenStack Placement
OpenStack Placement provides an HTTP service for managing, selecting, and claiming providers of classes of inventory representing available resources in a cloud.
API
To learn how to use Placement's API, consult the documentation available online at:
For more information on OpenStack APIs, SDKs and CLIs in general, refer to:
Operators
To learn how to deploy and configure OpenStack Placement, consult the documentation available online at:
In the unfortunate event that bugs are discovered, they should be reported to the appropriate bug tracker. If you obtained the software from a 3rd party operating system vendor, it is often wise to use their own bug tracker for reporting problems. In all other cases use the master OpenStack bug tracker, available at:
Developers
For information on how to contribute to Placement, please see the contents of CONTRIBUTING.rst.
Further developer focused documentation is available at: