CloudKitty (Rating) design specification
Go to file
yangyawei 2f2ea5d4b1 setup.cfg: Replace dashes with underscores
Setuptools v54.1.0 introduces a warning that the use of dash-separated
options in 'setup.cfg' will not be supported in a future version [1].
Get ahead of the issue by replacing the dashes with underscores. Without
this, we see 'UserWarning' messages like the following on new enough
versions of setuptools:

  UserWarning: Usage of dash-separated 'description-file' will not be
  supported in future versions. Please use the underscore name
  'description_file' instead

[1] https://github.com/pypa/setuptools/commit/a2e9ae4cb

Change-Id: I2d4c19cf44897668697cbfd6efc6d56b3a38d83f
2021-05-16 20:51:06 +00:00
doc/source Add "active" column to storage scope, and API to manage it 2021-02-19 15:05:21 +01:00
specs Merge "Add "active" column to storage scope, and API to manage it" 2021-02-24 16:58:44 +00:00
.gitignore Initialize cloudkitty-specs repo 2017-01-09 09:37:44 +08:00
.gitreview OpenDev Migration Patch 2019-04-19 19:34:34 +00:00
.zuul.yaml import zuul job settings from project-config 2018-08-31 08:57:19 -04:00
LICENSE Initialize cloudkitty-specs repo 2017-01-09 09:37:44 +08:00
README.rst Update and replace http with https for doc links 2019-08-22 14:54:05 +08:00
requirements.txt Switch to newer openstackdocstheme version 2020-08-24 11:17:21 +02:00
setup.cfg setup.cfg: Replace dashes with underscores 2021-05-16 20:51:06 +00:00
setup.py Initialize cloudkitty-specs repo 2017-01-09 09:37:44 +08:00
tox.ini Update tox config 2021-05-16 22:42:52 +02:00

OpenStack Cloudkitty Specifications

This git repository is used to hold approved design specifications for additions to the Cloudkitty project. Reviews of the specs are done in gerrit, using a similar workflow to how we review and merge changes to the code itself.

The layout of this repository is:

specs/<release>/

You can find an example spec in specs/template.rst.

Specifications are proposed for a given release by adding them to the specs/<release> directory and posting it for review. The implementation status of a story for a given release can be found by looking at the story in Storyboard. Not all stories will get fully implemented.

Specifications have to be re-proposed for every release. The review may be quick, but even if something was previously approved, it should be re-reviewed to make sure it still makes sense as written.

For more information about working with gerrit, see:

https://docs.openstack.org/infra/manual/developers.html#development-workflow

To validate that the specification is syntactically correct (i.e. get more confidence in the Jenkins result), please execute the following command:

$ tox

After running tox, the documentation will be available for viewing in HTML format in the doc/build/ directory.