Don't move specs from approved directory
When specs are approved but not yet implemented, they reside in specs/approved. After implementation, we have been moving them to specs/<release>-implemented. Which means that any links to specs in specs/approved are broken. This patch leaves the specs in specs/approved, and adds a new specs/not-implemented directory that contains soft links to all the approved-but-not-yet-implemented specs that reside in specs/approved. For specs that were implemented, e.g. in release 4.3, a specs/4.3 directory is created with soft links to the implemented specs (that still reside in specs/approved). Since we are using links to files, the specs cannot have labels because sphinx warns of duplicate labels. Change-Id: Icd81d68cec4bbfaa3b20e370ba1b31edb32ae1d1
This commit is contained in:
parent
6d9256c96d
commit
1b303b8142
18
README.rst
18
README.rst
|
@ -10,19 +10,27 @@ how we review and merge changes to the code itself.
|
|||
The layout of this repository is::
|
||||
|
||||
specs/approved/
|
||||
specs/backlog`/
|
||||
specs/<cycle>-implemented/
|
||||
specs/backlog/
|
||||
specs/not-implemented/
|
||||
specs/<release>/
|
||||
specs/<juno|kilo|liberty>-implemented/
|
||||
|
||||
There are also placeholder directories for old links that have been moved.
|
||||
|
||||
Specifications must follow the template which can be found at
|
||||
`doc/source/specs/template.rst`.
|
||||
|
||||
Specifications are proposed by adding them to the `specs/approved` directory
|
||||
and posting it for review. When a spec is fully implemented, it should be
|
||||
moved to specs/<cycle>-implemented. Not all approved blueprints will get
|
||||
Specifications are proposed by adding them to the `specs/approved` directory,
|
||||
adding a soft link to it from the `specs/not-implemented` directory, and
|
||||
posting it for review. When a specification is fully implemented, the link in
|
||||
`specs/not-implemented` directory should be moved to the appropriate
|
||||
`specs/<release>` directory. Not all approved specifications will get
|
||||
fully implemented.
|
||||
|
||||
Starting with the Mitaka development cycle, all approved specifications
|
||||
(implemented and not-implemented) will reside in the `specs/approved`
|
||||
directory.
|
||||
|
||||
Prior to the Juno development cycle, this repository was not used for spec
|
||||
reviews. Reviews prior to Juno were completed entirely through Launchpad
|
||||
blueprints::
|
||||
|
|
|
@ -37,7 +37,7 @@ implemented:
|
|||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
specs/approved/*
|
||||
specs/not-implemented/*
|
||||
|
||||
|
||||
Back-log of ideas
|
||||
|
@ -61,6 +61,15 @@ development cycles in which they were completed.
|
|||
Mitaka
|
||||
------
|
||||
|
||||
4.3
|
||||
~~~
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:maxdepth: 1
|
||||
|
||||
specs/4.3/*
|
||||
|
||||
Liberty
|
||||
-------
|
||||
|
||||
|
@ -116,6 +125,19 @@ Juno
|
|||
specs/kilo/*
|
||||
specs/juno/*
|
||||
|
||||
..
|
||||
----------------
|
||||
As of the start of the Mitaka development cycle, all approved specs
|
||||
will reside in specs/approved (not-yet-implemented as well as implemented
|
||||
specs). The files will not be moved (we hope). Instead, we will create
|
||||
directories with links to these files. The specs/approved directory
|
||||
will be hidden.
|
||||
|
||||
.. toctree::
|
||||
:glob:
|
||||
:hidden:
|
||||
|
||||
specs/approved/*
|
||||
|
||||
==================
|
||||
Indices and tables
|
||||
|
|
|
@ -0,0 +1 @@
|
|||
../approved/iscsi-deploy-in-band-cleaning.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/new-ironic-driver-for-oneview.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/radosgw-temp-url.rst
|
|
@ -52,7 +52,8 @@ The main differences will be:
|
|||
|
||||
* operators will be able to initiate a manual clean via the modified API
|
||||
to set the nodes's provision state. Details are described in the
|
||||
:ref:`ProvisionCleanAPI` section.
|
||||
`PUT .../states/provision <#put-v1-nodes-node-ident-states-provision>`_
|
||||
section below.
|
||||
|
||||
* A manual clean step might need some arguments to be specified. (This might
|
||||
be useful for future automated steps too.) To support this, the
|
||||
|
@ -72,7 +73,8 @@ The main differences will be:
|
|||
include any arguments that can be passed to the clean step.
|
||||
|
||||
* operators will be able to get a list of possible steps via an API. The
|
||||
:ref:`CleanStepsAPI` section provides more information.
|
||||
`GET .../cleaning/steps <#get-nodes-node-ident-cleaning-steps>`_ section
|
||||
below provides more information.
|
||||
|
||||
* similar to executing automated clean steps, when the conductor attempts to
|
||||
execute a manual clean step, it will call execute_clean_step() on the driver
|
||||
|
@ -121,8 +123,6 @@ This:
|
|||
REST API impact
|
||||
---------------
|
||||
|
||||
.. _ProvisionCleanAPI:
|
||||
|
||||
PUT /v1/nodes/<node_ident>/states/provision
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
@ -173,7 +173,6 @@ be put in CLEANFAIL provision state with an appropriate error message.
|
|||
|
||||
A new API version is needed to support this.
|
||||
|
||||
.. _CleanStepsAPI:
|
||||
|
||||
GET /nodes/<node_ident>/cleaning/steps
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
@ -0,0 +1 @@
|
|||
../approved/add-pluggable-metrics-backend-for-ironic-and-ipa.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/agent-image-proxy.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/bare-metal-trust-using-intel-txt.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/cisco-ucs-hw-inspection.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/futurist.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/inband-raid-configuration.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/ipxe-dynamic-config.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/ipxe-swift-tempurls.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/ironic-generic-raid-interface.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/ironic-ml2-integration.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/manual-cleaning.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/network-provider.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/nodes-tagging.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/notifications.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/override-pxe-options-via-glance-property.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/petitboot-boot-driver.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/ssh-console-support.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/third-party-ci.rst
|
|
@ -0,0 +1 @@
|
|||
../approved/version-caching.rst
|
Loading…
Reference in New Issue