b09f2f917f
The Trait and ResourceClass db objects have the same essential structure and are used throughout the code in similar ways: * turn a name into an id * turn an id into a name * get an unfiltered list of names * make a mapping of ids to names In I409a5e819a72d64e66ee390e4528da0c503d8d05 we made the resource class cache request specific. Doing that work made it pretty clear we could have a similar cache for traits and as a result visit the traits db fewer times per request. The implementation is straightforward: make an _AttributeCache super class that is a parent to ResourceClassCache. Create TraitCache as a sibling. The sole difference is the table used for the data authority and the exception raised when an attribute is not found. The new super class has been refactored to use private attributes and methods. A 'get_all' method is added to the cache to list the full collection of dicts it contains. That can be be directly transformed into Trait and ResourceClass objects. The order of the results of this method are not predictable, and sorting them would add cost for no benefit, so gabbi tests which had previously relied on the ordered of returned resource classes have been removed. From the API, listing traits and resource classes (without filters) now uses the cache instead of going to the db. Where filters (in traits) are required, the db is accessed. The research_context turns lists of trait names into id, name maps for required and forbidden traits. Further, anywhere the traits table was joined to create a name of an id, the cache is used instead. This allows to drop some joins and operate fully in-process and in-RAM. No additional loops are added to make this happen: the translation is done in existing loops. The upshot of these changes is that unless there is a write operation on a trait or resource class, both tables are scanned at most once in any request. And when they are scanned it is to list their entire contents. As noted in the _AttributeCache docstring there are restrictions on what kinds of entities can use the cache and some necessary precautions. Change-Id: Ia19ea2b4ecdde25323579edf60ad6269d05e75a2 |
||
|---|---|---|
| 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: