Merge "Cleanup specs folder"
This commit is contained in:
commit
5e55719280
@ -1,19 +1,40 @@
|
||||
Specifications
|
||||
==============
|
||||
Project Specifications
|
||||
======================
|
||||
|
||||
Contents:
|
||||
Specifications in this repository represent a consensus on the topics covered
|
||||
within. They should be considered a mandate on the path forward with regards
|
||||
to the content on which they are drafted.
|
||||
|
||||
Here is a list of the current specs:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:glob:
|
||||
|
||||
developer-environment.rst
|
||||
osh-lma-stack.rst
|
||||
specifications.rst
|
||||
template.rst
|
||||
neutron-multiple-sdns.rst
|
||||
nginx-sidecar.rst
|
||||
support-linux-bridge-on-neutron.rst
|
||||
fluentbit-fluentd-architecture.rst
|
||||
osh-1.0-requirements.rst
|
||||
values-ordering.rst
|
||||
tenant-ceph.rst
|
||||
*
|
||||
|
||||
Specifications Purpose
|
||||
----------------------
|
||||
|
||||
A specification should precede any broad-reaching technical changes or proposals
|
||||
to OpenStack-Helm. Examples of changes requiring a specification include: a
|
||||
standard format to the values.yaml files, multiple backend support for neutron,
|
||||
and the approach for logging and monitoring in OpenStack-Helm. Some additional
|
||||
features will not need an accompanying specification, but may be tied back to an
|
||||
existing specification. An example of this would be introducing a service in
|
||||
OpenStack-Helm that could be included under the scope of a specification already
|
||||
drafted and approved.
|
||||
|
||||
Specifications Process
|
||||
----------------------
|
||||
|
||||
Before drafting a specification, a blueprint should be filed in Storyboard_
|
||||
along with any dependencies the blueprint requires. Once the blueprint has been
|
||||
registered, submit the specification as a patch set to the specs/ directory
|
||||
using the supplied template.
|
||||
|
||||
More information about the blueprint + specification lifecycle can be found
|
||||
here_.
|
||||
|
||||
.. _Storyboard: https://storyboard.openstack.org/#!/project_group/64
|
||||
.. _here: https://wiki.openstack.org/wiki/Blueprints#Blueprints_and_Specs
|
||||
|
@ -1,33 +0,0 @@
|
||||
=====================
|
||||
Project Specfications
|
||||
=====================
|
||||
|
||||
Specifications in this repository represent a consensus on the topics covered
|
||||
within. They should be considered a mandate on the path forward with regards
|
||||
to the content on which they are drafted.
|
||||
|
||||
Purpose
|
||||
-------
|
||||
|
||||
A specification should precede any broad-reaching technical changes or proposals
|
||||
to OpenStack-Helm. Examples of changes requiring a specification include: a
|
||||
standard format to the values.yaml files, multiple backend support for neutron,
|
||||
and the approach for logging and monitoring in OpenStack-Helm. Some additional
|
||||
features will not need an accompanying specification, but may be tied back to an
|
||||
existing specification. An example of this would be introducing a service in
|
||||
OpenStack-Helm that could be included under the scope of a specification already
|
||||
drafted and approved.
|
||||
|
||||
Process
|
||||
-------
|
||||
|
||||
Before drafting a specification, a blueprint should be filed in Storyboard_
|
||||
along with any dependencies the blueprint requires. Once the blueprint has been
|
||||
registered, submit the specification as a patch set to the specs/ directory
|
||||
using the supplied template.
|
||||
|
||||
More information about the blueprint + specification lifecycle can be found
|
||||
here_.
|
||||
|
||||
.. _Storyboard: https://storyboard.openstack.org/#!/project_group/64
|
||||
.. _here: https://wiki.openstack.org/wiki/Blueprints#Blueprints_and_Specs
|
Loading…
Reference in New Issue
Block a user