9ef7c2ca0c
RefStack recently added features to enable the uploading of data with key. Currently, RefStack accepts the uploaded data regardless of whether the keys exist in RefStack or not. This spec describes the validation process update needed to ensure that RefStack only accepts data with those keys that are previously imported into RefStack. Change-Id: I5bb7de969fe92258d54a64feec01310afcf91038 |
||
|---|---|---|
| .. | ||
| approved | ||
| proposed | ||
| README.rst | ||
| template.rst | ||
Refstack Specifications
This folder is used to hold design specifications for additions to the Refstack project. Reviews of the specs are done in gerrit, using a similar workflow to how we review and merge changes to the code itself.
Specifications are proposed by adding an .rst file to the specs/proposed directory and posting it for review. Not all approved blueprints will get fully implemented. You can find an example spec in /specs/template.rst.
When a spec has passed the review process and discussions in our weekly meetings it will be moved to 'specs/approved/'. At that time the blueprint will be marked as approved and assigned to someone.
Once a spec has been fully implemented, meaning a patch has landed that references the blueprint, it will be moved again to 'specs/completed'.
Prior to April 2014, this method was not used for spec reviews. Prior reviews were completed entirely through Launchpad blueprints:
http://blueprints.launchpad.net/refstackPlease note, Launchpad blueprints are still used for tracking the current status of blueprints. For more information, see:
https://wiki.openstack.org/wiki/BlueprintsFor more information about working with gerrit, see:
http://docs.openstack.org/infra/manual/developers.html#development-workflowTo validate that the specification is syntactically correct (i.e. get more confidence in the Jenkins result), please execute the following command:
$ tox