openstack/cloudkitty-specs
Code Issues Proposed changes
CloudKitty (Rating) design specification
40 Commits 1 Branch 0 Tags 724 KiB
Python 100%
e55dd78b26
Go to file
Ghanshyam Mann e55dd78b26 [ussuri][goal] Drop python 2.7 support 
OpenStack is dropping the py2.7 support in ussuri cycle.

specs repo has py2 specific requirement which is removed
or tox optimization.

Ussuri Communtiy-wide goal:
https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html

Change-Id: I4544d8d1192539d50bca836f6699261658ae38ed
2019-12-13 00:48:38 +00:00
doc/source Spec: V1 API rating modules endpoints migration to V2 API 2019-10-07 10:10:35 +02:00
specs Merge "Spec: Add query functions to Prometheus" 2019-12-02 10:22:09 +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 Refreshing the repository 2018-10-25 16:39:58 +02:00
requirements.txt Add support for PDF documentation 2019-09-17 10:00:02 +02:00
setup.cfg Fix author-email in setup.cfg 2019-01-22 16:27:16 +08:00
setup.py Initialize cloudkitty-specs repo 2017-01-09 09:37:44 +08:00
tox.ini [ussuri][goal] Drop python 2.7 support 2019-12-13 00:48:38 +00:00

README.rst

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:

http://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.