openstack
/
placement
Code Issues Proposed changes
OpenStack resource provider inventory allocation service
11,110 Commits 9 Branches 46 Tags 21 MiB
Python 93%
PHP 4.3%
Shell 2.6%
Go to file
Chris Dent 48948bce9e Initial structure for in-tree specs 
We decided in IRC and email discussions that henceforth
placement specs will reside in the same tree as code and docs.
This change sets that up using the following structure:

* There is a docs/source/specs top-level index that should be
  updated with each release to include tables of contents generated
  from cycle directories (currently pointing to train) for
  approved and implemented specs.

* In the approved directory for any cycle there will be a
  <cycle-template>.rst file to use as the basis for any new
  spec. New specs go in this directory.

* In the implemented directory is a placeholder file which
  will be removed when the first (if any) spec moves from
  approved (meaning in-progress) to implemented. The PTL
  or their designee will be responsible for doing that moving.
  The placeholder file is required to avoid warnings (which
  will kill the tox docs job) from the table of contents
  globbing.

* The train-template.rst is a copy-with-edits from nova's
  version of the same thing. The main changes are to indicate
  that StoryBoard, not launchpad blueprints, are the starting
  point and to remove various nova-isms.

  It is likely we will want to further tweak the template as
  we decide what matters.

The next steps for this are for people with placement specs
that had been pending in nova in stein, to resubmit them to
placement as train specs (in doc/source/specs/train/approved).
It is quite likely and not surprising that it will sometimes
be confusing whether a spec should be in nova or placement.
Ideally we can identify the "just placement" aspects of a
change and make a placement-only spec for that which the nova
spec makes reference to. This may sound like a pain but it is
a feature, not a bug, which helps make sure that placement
evolves its API as a strong contract for all potential clients.

Change-Id: I85854d771409701cea2fcf7a218f02af60dba72e
 		2019-03-22 13:33:09 +00:00
api-ref Update docs bug links to storyboard 2019-03-11 20:54:24 +00:00
doc Initial structure for in-tree specs 2019-03-22 13:33:09 +00:00
etc/placement Add oslo.log to genconfig 2019-03-19 09:47:14 -05:00
gate Add a perfload job. 2018-11-30 14:59:47 +00:00
placement Add register_opts param to PlacementFixture 2019-03-20 22:34:21 +00:00
playbooks Use sync_on_startup in placement-perfload job 2019-03-09 12:24:22 +00:00
releasenotes Update master for stable/stein 2019-03-20 20:47:31 +00:00
tools Add stamp DB version to the migration script 2018-12-12 00:26:57 +00:00
.coveragerc Use both unit and functional for coverage testing 2018-09-14 13:30:14 -06:00
.gitignore Clean up .gitignore file 2018-10-16 00:14:36 +09:00
.gitreview Set up initial .zuul.yaml 2018-08-31 14:24:59 +00:00
.stestr.conf Put stestr group_regex in .stestr.conf 2018-09-14 13:30:14 -06:00
.zuul.yaml Merge "Add irrelevant files list to perfload job" 2019-01-22 04:41:13 +00:00
CONTRIBUTING.rst Update CONTRIBUTING and HACKING 2019-03-11 18:28:36 +00:00
LICENSE initial commit 2010-05-27 23:05:26 -07:00
README.rst Update CONTRIBUTING and HACKING 2019-03-11 18:28:36 +00:00
babel.cfg Get rid of distutils.extra. 2012-02-08 19:30:39 -08:00
bindep.txt Merge "Bindep does not catch missing libpcre3-dev on Ubuntu" 2018-02-14 07:31:09 +00:00
lower-constraints.txt Don't use OVO with ResourceProvider and ResourceProviderList 2019-02-25 23:48:33 +00:00
requirements.txt Don't use OVO with ResourceProvider and ResourceProviderList 2019-02-25 23:48:33 +00:00
setup.cfg Update author-email in setup.cfg 2018-12-04 04:21:17 +00:00
setup.py Updated from global requirements 2017-03-02 11:50:48 +00:00
test-requirements.txt Correct lower-constraints.txt and the related tox job 2018-11-27 17:41:02 +00:00
tox.ini Remove pep8 whitespace ignores 2019-03-05 18:18:30 -06:00

README.rst

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

image

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: