c8ab9ff906
Added alembic, and created an initial database revision. For the sake of testing with real databases, tools/test-setup.sh is added so that CI can start up a mysql and/or postgresql database on which to test migrations. The OpportunisticDBMixin from oslo_db was originally used for this, but because of the way placement configures the database this proved hard to debug and get correct, so we've used something that leverages the available oslo_db tools, but with more visibility. Because these tests mix sqlite, mysql and postgresql settings in the potentially the same process we need a way to insure that global settings for databases do not leak into other tests. This is done with a reset() on the placement db fixture, called by the msyql and postgresql tests before and after they run. We also need careful management of that cleanup when these tests are skipped (because db server or database is not there). Those tests will confirm that the models match the migrations so we also need to remove model files that no longer matter. Since we no longer need to distinguish among multiple database files, we can simplify the naming of these files. Co-Authored-By: Chris Dent <cdent@anticdent.org> Change-Id: I51ed1e4e7dbb76a3eab23af7d0d106f716059112
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: