openstack
/
cinder-specs
Code Issues Proposed changes

Resolve Sphinx Issues 

With the release of Sphinx 4.4.0 this highlighed issues with duplicate
labels across multiple specs.

This patch fixes all the duplicate labels.

Change-Id: I9baf7c51e2fe9c397feae05a975ddecae7dceba8
This commit is contained in:
Simon Dodsley 2022-01-25 11:13:34 -05:00
parent cbb9701c60
commit 591d155bda
12 changed files with 58 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
specs/kilo/linux-systemz.rst
View File

@ -248,8 +248,8 @@ Documentation Impact
References
==========
* _`[1]` Linux on System z Device Driver book,
* Linux on System z Device Driver book,
http://public.dhe.ibm.com/software/dw/linux390/docu/l316dd25.pdf
* _`[2]` Linux on System z,
* Linux on System z,
http://www.ibm.com/developerworks/linux/linux390/

4
specs/newton/linux-ficon-support.rst
View File

@ -282,9 +282,9 @@ Documentation Impact
References
==========
* _`[1]` Linux on System z Device Driver book,
* Linux on System z Device Driver book,
http://public.dhe.ibm.com/software/dw/linux390/docu/l316dd25.pdf
* _`[2]` Linux on System z,
* Linux on System z,
http://www.ibm.com/developerworks/linux/linux390/

18
specs/pike/add-like-filter.rst
View File

@ -21,7 +21,7 @@ Currently, we could only filter cinder resource by exact match, and this is
not flexible enough when user would like to retrieve some resource whose name
or attribute is partly alike, especially for the users who have lots of
volumes. As it's already introduced in many other projects, we can take
advantage of those some existing mechanism, nova `[1]`_ and ironic `[2]`_.
advantage of those some existing mechanism, `nova`_ and `ironic`_.
Use Cases
=========
@ -33,7 +33,7 @@ Proposed change
===============
Although we can provide filtering resource based on regex filter, but there
is a possibility that we could have ReDos `[3]`_ attack. Considering the
is a possibility that we could have `ReDos`_ attack. Considering the
'LIKE' operator is flexible and safe enough for this case. We could only
introduce 'LIKE' operator ('NOT LIKE' is another useful operator, but it's
not as common as 'LIKE'). And we can easily apply this filter at the
@ -44,8 +44,8 @@ existing common filtering function individually with a decorator::
pass
This spec intends to support 'LIKE' based filter on some specified resources
and columns, as we would have the generalized resource filtering feature
`[4]`_, this one will take advantage of that spec in order to make it
and columns, as we would have the generalized `resource filtering`_ feature,
this one will take advantage of that spec in order to make it
configurable for administrators, so this is what we would finally have in our
filters' configuration file ::
@ -150,7 +150,7 @@ Work Items
Dependencies
============
Depended on generalized resource filtering `[4]`_
Depended on generalized `resource filtering`_
Testing
=======
@ -165,8 +165,8 @@ Update API documentation.
References
==========
_`[1]`: https://review.openstack.org/#/c/45026/
_`[2]`: https://review.openstack.org/#/c/266688/
_`[3]`: https://en.wikipedia.org/wiki/ReDoS
_`[4]`: https://review.openstack.org/#/c/441516/
_`nova`: https://review.openstack.org/#/c/45026/
_`ironic`: https://review.openstack.org/#/c/266688/
_`reDos`: https://en.wikipedia.org/wiki/ReDoS
_`resource filtering`: https://review.openstack.org/#/c/441516/

6
specs/pike/add-volume-type-filter-to-get-pools.rst
View File

@ -55,7 +55,7 @@ support for this filter in logic:
* the filter properties of ``get_filtered_hosts`` only consists of volume-type
properties.
* As already proposed by generalized resource filtering `[1]`, the changes on
* As already proposed by generalized resource filtering [1]_, the changes on
cinder-client for this feature are not needed.
@ -132,7 +132,7 @@ Work Items
Dependencies
============
Depended on generalized resource filtering `[1]`_
Depended on generalized resource filtering [1]_
Testing
=======
@ -150,4 +150,4 @@ Documentation Impact
References
==========
_`[1]`: https://review.openstack.org/#/c/441516/
.. [1] https://review.openstack.org/#/c/441516/

8
specs/pike/cinder-volume-revert-by-snapshot.rst
View File

@ -15,7 +15,7 @@ snapshot. The revert function can be used to revert a volume to a previous
snapshot, restoring the volume to the state at the time the snapshot was
created. The feature supports reverting a volume to the most recent snapshot
taken, also manila (shared file system service) has already supported what
we are proposing in Ocata `[1]`_.
we are proposing in Ocata [1]_.
The revert process will overwrite the current state and data of the volume.
If the volume was extended after the snapshot, the request would be rejected
@ -126,7 +126,7 @@ As we support extend volumes at present, we could meet the case that
snapshot is smaller than volume when reverting to snapshot and it's obviously
safe to revert in that case. But we will still restrict to revert the volume
which current volume size is equal to snapshot, cause we don't support shrink
volume yet `[2]`_ (that ability will be used in the generic method, if the
volume yet [2]_ (that ability will be used in the generic method, if the
driver don't support revert to snapshot).
Therefore, we need to do the following changes in order to support volume
@ -356,5 +356,5 @@ Documentation Impact
References
==========
_`[1]`: https://specs.openstack.org/openstack/manila-specs/specs/ocata/manila-share-revert-to-snapshot.html
_`[2]`: https://wiki.openstack.org/wiki/CinderSupportMatrix
.. [1] https://specs.openstack.org/openstack/manila-specs/specs/ocata/manila-share-revert-to-snapshot.html
.. [2] https://wiki.openstack.org/wiki/CinderSupportMatrix

5
specs/pike/explicit-user-messages.rst
View File

@ -134,7 +134,7 @@ Alternatives
------------
The alternatives is we could keep adding user messages in the way of we
currently have `[1]`_. (There could be more alternatives or better solutions,
currently have [1]_. (There could be more alternatives or better solutions,
but I failed to figure out.)
Data model impact
@ -215,5 +215,4 @@ Documentation Impact
References
==========
_`[1]` https://review.openstack.org/#/c/298052/
.. [1] https://review.openstack.org/#/c/298052/

20
specs/queens/add-count-info-in-list-response.rst
View File

@ -38,7 +38,7 @@ REST APIs, so find out what are others are doing may help us to have a
better API model for this case.
1. Facebook API support the ``total_count`` attribute in their list
APIs `[1]`_. And this is their API response::
APIs [1]_. And this is their API response::
{
"data": [],
@ -49,7 +49,7 @@ better API model for this case.
}
2. JSON API org adds an example to demonstrate the usage of ``total-pages`` or
``count`` in their recommended examples `[2]`_::
``count`` in their recommended examples [2]_::
{
"meta": {
@ -65,7 +65,7 @@ better API model for this case.
}
3. StackExchange API also adds the total attribute in their
``Common Wrapper Object`` `[3]`_. And this is how their response
``Common Wrapper Object`` [3]_. And this is how their response
looks like::
{
@ -88,7 +88,7 @@ response (take volume for example)::
So, this bp proposes to add new attribute ``count`` in our list APIs (
including index and detail).
Based on our current pagination system `[4]`_, if we add the ``count``
Based on our current pagination system [4]_, if we add the ``count``
attribute into our response body in default, the db's query statement would
be executed twice for only one query which obviously has a performance
impact, considering not every request requires this kind of info, the
@ -98,7 +98,7 @@ resource::
/v3/{tenant_id}/{resource}?with_count=true
/v3/{tenant_id}/{resource}/detail?with_count=true
Also, this is recommended by OpenStack API-WG `[5]`_.
Also, this is recommended by OpenStack API-WG [5]_.
For the first step we only plan to add the summary support for our main
resources: ``volumes``, ``snapshots`` and ``backups``.
@ -220,11 +220,11 @@ Update API documentation.
References
==========
_`[1]`: https://developers.facebook.com/docs/graph-api/reference/v2.1/user/friends
_`[2]`: http://jsonapi.org/examples/
_`[3]`: https://api.stackexchange.com/docs/wrapper
_`[4]`: https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/api.py#L2324
_`[5]`: https://github.com/openstack/api-wg/blob/64e3e9b07272f50353429dc51d98524642ab6d67/guidelines/counting.rst
.. [1] https://developers.facebook.com/docs/graph-api/reference/v2.1/user/friends
.. [2] http://jsonapi.org/examples/
.. [3] https://api.stackexchange.com/docs/wrapper
.. [4] https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/api.py#L2324
.. [5] https://github.com/openstack/api-wg/blob/64e3e9b07272f50353429dc51d98524642ab6d67/guidelines/counting.rst

6
specs/queens/create-volume-from-backup.rst
View File

@ -43,7 +43,7 @@ users can directly create a new volume with backup id as below:
Volume's size is equal to the backup's original volume size if size
option is omitted.
Since we already introduced the generic backup implementation `[1]`_ for our
Since we already introduced the generic backup implementation [1]_ for our
existing volume drivers, it makes sense to add this ability to our volume
drivers, so when create volume from backup, the request will be scheduled
to the volume backend as normal, and first we would try the vendor-specific
@ -147,7 +147,7 @@ Work Items
Dependencies
============
Depends on generic backup implementation `[1]`_
Depends on generic backup implementation [1]_
Testing
=======
@ -162,4 +162,4 @@ Both API documentation and CLI documentation should be updated.
References
==========
* _`[1]`: https://github.com/openstack/cinder-specs/blob/master/specs/queens/generic-backup-implementation.rst
.. [1] https://github.com/openstack/cinder-specs/blob/master/specs/queens/generic-backup-implementation.rst

4
specs/rocky/support-az-in-volume-type.rst
View File

@ -29,7 +29,7 @@ users can know valid volume types in current AZ.
Proposed change
===============
As the discussion result during Rocky PTG `[1]`_, we would propose to use
As the discussion result during Rocky PTG [1]_, we would propose to use
volume type's ``extra specs`` to support this. Since ``extra specs`` is
designed for generic use, we would propose to introduce a reserved key
``os-extended:availability_zones`` for extra specs. Administrator can
@ -184,4 +184,4 @@ Documentation Impact
References
==========
_`[1]`: https://etherpad.openstack.org/p/cinder-ptg-rocky-wednesday
.. [1] https://etherpad.openstack.org/p/cinder-ptg-rocky-wednesday

7
specs/rocky/support-filter-backend-on-operation-type.rst
View File

@ -25,7 +25,7 @@ based on our current logic.
Use Cases
=========
We have discussed the concept of **sold out** during Rocky PTG `[1]`_ and
We have discussed the concept of **sold out** during Rocky PTG [1]_ and
that word is more related to administrative operation, when most of an
specific pool's capacity has been consumed, administrators need the
functionality to mark the backend pool sold out, that is to say, it
@ -169,5 +169,6 @@ References
==========
_`[1]`: https://etherpad.openstack.org/p/cinder-ptg-rocky-wednesday
_`[2]`: https://review.openstack.org/#/c/308869/
.. [1] https://etherpad.openstack.org/p/cinder-ptg-rocky-wednesday
* https://review.openstack.org/#/c/308869/

32
specs/rocky/support-image-signature-verification.rst
View File

@ -16,7 +16,7 @@ provide end users with stronger assurances of the integrity of the image data
they are using to create volumes. This change will use the same data model for
image metadata as the accompanying functionality in Glance, which will allow
the end user to sign images and verify these image signatures upon
upload `[1]`_.
upload [1]_.
Problem description
===================
@ -24,7 +24,7 @@ Problem description
Previously, OpenStack's protection against unexpected modification of images
was limited to verifying an MD5 checksum. While this may be sufficient for
protecting against accidental modifications, MD5 is a hash function, not an
authentication primitive `[2]`_, and thus provides no protection against
authentication primitive [2]_, and thus provides no protection against
deliberate, malicious modification of images. An image could potentially be
modified in transit, such as when it is uploaded to Glance or transferred to
Cinder. An image that is modified could include malicious code.
@ -79,7 +79,7 @@ follows:
* img_signature_key_type - A string designating the signature scheme used to
generate the signature. For more detail on which are currently supported,
please check Glance's documentation `[7]`_.
please check Glance's documentation [7]_.
* img_signature_certificate_uuid - A string encoding the certificate
uuid used to retrieve the certificate from the key manager.
@ -107,7 +107,7 @@ Proposed change
===============
Since Nova has implemented this feature and all of the verification process
has been moved into ``cursive`` module `[4]`_, it's more convenient to support
has been moved into ``cursive`` module [4]_, it's more convenient to support
this in Cinder now.
**Verify image signature with certificate**
@ -183,7 +183,7 @@ image metadata when creating from image.
This feature tries to find a way to determine if the certificate
used to generate and verify that signature is a certificate that
is trusted by the user, we could find more detail in Nova spec `[5]`_.
is trusted by the user, we could find more detail in Nova spec [5]_.
In short, within that feature end user can also validate the image's
certificate with the given trusted certificates (specified via API
or config option).
@ -276,7 +276,7 @@ This change will involve adding log messages to indicate the success or
failure of signature verification and creation.
A later change will involve notifying the user about failure in case signature
verification fails, this will use async error notification feature `[3]`_.
verification fails, this will use async error notification feature [3]_.
Other end user impact
---------------------
@ -303,9 +303,9 @@ decrypting a signature using a public key.
Other deployer impact
---------------------
We will recommend you deploy Barbican service `[6]`_ to store your
We will recommend you deploy Barbican service [6]_ to store your
certificate information as other projects suggest, although you can integrate
any other secret manager service via Castellan `[8]`_.
any other secret manager service via Castellan [8]_.
Developer impact
@ -363,11 +363,11 @@ References
Cryptography API: https://pypi.org/project/cryptography/0.2.2
_`[1]` https://review.openstack.org/#/c/252462/
_`[2]` https://en.wikipedia.org/wiki/MD5#Security
_`[3]` https://blueprints.launchpad.net/cinder/+spec/summarymessage
_`[4]` https://git.openstack.org/cgit/openstack/cursive
_`[5]` http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nova-validate-certificates.html
_`[6]` https://docs.openstack.org/barbican/latest/
_`[7]` https://docs.openstack.org/glance/pike/user/signature.html
_`[8]` https://wiki.openstack.org/wiki/Castellan
.. [1] https://review.openstack.org/#/c/252462/
.. [2] https://en.wikipedia.org/wiki/MD5#Security
.. [3] https://blueprints.launchpad.net/cinder/+spec/summarymessage
.. [4] https://git.openstack.org/cgit/openstack/cursive
.. [5] http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nova-validate-certificates.html
.. [6] https://docs.openstack.org/barbican/latest/
.. [7] https://docs.openstack.org/glance/pike/user/signature.html
.. [8] https://wiki.openstack.org/wiki/Castellan

2
specs/stein/support-deferred-deletion-in-rbd.rst
View File

@ -171,4 +171,4 @@ Documentation Impact
References
==========
_`[1]`: https://review.openstack.org/#/c/550858/
* https://review.openstack.org/#/c/550858/