2fc321aea3
Experimentation led to the discovery (as described in the story noted below) that the global RC_CACHE is not safe in a multi-process environment, which is common for a web service designed to scale horizontally. In rare circumstances it is possible for a custom resource class to be deleted in one process but still appear to exist in another. For many situations this wouldn't really matter, but there are cases, even more rare, where it would be possible to write allocations or resource provider inventory using the wrong resource class id. On the related story, a variety of options were discussed to fix this. Reading through the code this one (which is option 2) was the only one that proved workable in a relatively straightforward fashion: Have a per request cache. To that end, when a RequestContext is created (per request) the resource class table is scanned to create a cache. Because the context is local to this request, we no longer need to do any locking around the cache, either when we create it or when we clear it: The caller is linear. The cost of this is that now every single request starts with a scan of the resource class table. This isn't horrible: if we had no cache at all we'd be reading rows from that table multiple times throughout any request (read or write). We should probably do some performance analysis to see what the impact of this might be. The perfload jobs may be able to give a limited sense of what the impact is, but profiling will be required for accuracy. It is the case that the functional tests seem a bit slower because of that additional db query. Change-Id: I409a5e819a72d64e66ee390e4528da0c503d8d05 Story: 2006232 Task: 35833
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: