bed7808b59
Turn ResourceProvider and ResourceProviderList into classical Python objects. There are two changes here which deserve particular attention because they are more changing than the other OVO removals: * There were two deepcopy calls in the allocation request handling. When using OVO, the __deepcopy__ handling built into it prevents deep recursion. I changed them to copy and things still work as expected. This will be because using the nested objects by reference is acceptable. * The removal of OVO removes the detection of changed fields. This was being used when creating and saving resource providers (at the object level) to automagically detect and prevent writing fields we don't want to. This change removes that functionality. Instead if bad data has made it as far as the create or save calls, we simply don't write it. The HTTP layer continues to maintain the guards it already had in place to prevent badness. Tests which were testing the object layer are removed. The create_provider function in functional/db/test_base allowed (trying to) create a provider with a root but that functionality was only called from one place. That place and the functionality in create_provider is removed. Other things to note: * As with the other changes, where context is actually used by the object it is required in the constructor. This cascades some changes to tests. * A test that checks to see if adding traits resets the changes on a rp has been removed, because we don't track that any more if we haven't got OVO. * The last_modified handling in placement/util no longer need NotImplemented handling, that was an artifact of OVO. oslo.versionedobjects is removed from requirements. This doesn't have a huge impact on the size of the virtualenv: 114M -> 107M [1] but it does take us from 132 python dependencies (via pip list) to 119, removing plenty of stuff that was only being called in because stuff that we don't use depended on it. lower-constraints.txt is updated to reflect the removal of dependencies that are no longer needed. [1] Of note, 26M of that is babel. Do we need to translate exceptions? See email disussion at http://lists.openstack.org/pipermail/openstack-discuss/2019-February/thread.html#3002 Change-Id: Ie0a9351e0d7c762c9c96c45cbe50132a0fbd1486
Warning: This repository is currently in a state of flux as the placement service is extracted from nova. While that is happening this repository is not yet fully working.
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:
For the time being bugs in placement should be created in the Nova bug tracker with a tag of ``placement``.
Developers
For information on how to contribute to Placement, please see the contents of CONTRIBUTING.rst.
Any new code must follow the development guidelines detailed in the HACKING.rst file, and pass all tests.
Further developer focused documentation is available at: