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

specs/kilo/linux-systemz.rst

@@ -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/

specs/newton/linux-ficon-support.rst

@@ -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/
 

specs/pike/add-like-filter.rst

@@ -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
+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
+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/
+_`nova`: https://review.openstack.org/#/c/45026/
-_`[2]`: https://review.openstack.org/#/c/266688/
+_`ironic`: https://review.openstack.org/#/c/266688/
-_`[3]`: https://en.wikipedia.org/wiki/ReDoS
+_`reDos`: https://en.wikipedia.org/wiki/ReDoS
-_`[4]`: https://review.openstack.org/#/c/441516/
+_`resource filtering`: https://review.openstack.org/#/c/441516/
 

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

@@ -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/

specs/pike/cinder-volume-revert-by-snapshot.rst

@@ -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
+.. [1] https://specs.openstack.org/openstack/manila-specs/specs/ocata/manila-share-revert-to-snapshot.html
-_`[2]`: https://wiki.openstack.org/wiki/CinderSupportMatrix
+.. [2] https://wiki.openstack.org/wiki/CinderSupportMatrix

specs/pike/explicit-user-messages.rst

@@ -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/

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

@@ -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
+.. [1] https://developers.facebook.com/docs/graph-api/reference/v2.1/user/friends
-_`[2]`: http://jsonapi.org/examples/
+.. [2] http://jsonapi.org/examples/
-_`[3]`: https://api.stackexchange.com/docs/wrapper
+.. [3] https://api.stackexchange.com/docs/wrapper
-_`[4]`: https://github.com/openstack/cinder/blob/master/cinder/db/sqlalchemy/api.py#L2324
+.. [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
+.. [5] https://github.com/openstack/api-wg/blob/64e3e9b07272f50353429dc51d98524642ab6d67/guidelines/counting.rst
 
 
 

specs/queens/create-volume-from-backup.rst

@@ -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

specs/rocky/support-az-in-volume-type.rst

@@ -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

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

@@ -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
+.. [1] https://etherpad.openstack.org/p/cinder-ptg-rocky-wednesday
-_`[2]`: https://review.openstack.org/#/c/308869/
+
+* https://review.openstack.org/#/c/308869/

specs/rocky/support-image-signature-verification.rst

@@ -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/
+.. [1] https://review.openstack.org/#/c/252462/
-_`[2]` https://en.wikipedia.org/wiki/MD5#Security
+.. [2] https://en.wikipedia.org/wiki/MD5#Security
-_`[3]` https://blueprints.launchpad.net/cinder/+spec/summarymessage
+.. [3] https://blueprints.launchpad.net/cinder/+spec/summarymessage
-_`[4]` https://git.openstack.org/cgit/openstack/cursive
+.. [4] https://git.openstack.org/cgit/openstack/cursive
-_`[5]` http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nova-validate-certificates.html
+.. [5] http://specs.openstack.org/openstack/nova-specs/specs/queens/approved/nova-validate-certificates.html
-_`[6]` https://docs.openstack.org/barbican/latest/
+.. [6] https://docs.openstack.org/barbican/latest/
-_`[7]` https://docs.openstack.org/glance/pike/user/signature.html
+.. [7] https://docs.openstack.org/glance/pike/user/signature.html
-_`[8]` https://wiki.openstack.org/wiki/Castellan
+.. [8] https://wiki.openstack.org/wiki/Castellan

specs/stein/support-deferred-deletion-in-rbd.rst

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