openstack/cinder-specs
Code Issues Proposed changes

Fix Sphinx warnings in existing Cinder specs

Browse Source 
Sphinx throws warnings on two of existing spec files:

> cinder-specs/doc/source/specs/liberty/clone-image-in-glance-cinder-backend.rst:173:
  WARNING: Footnote [2] is not referenced.
> cinder-specs/doc/source/specs/newton/discovering-system-capabilities.rst:356:
  WARNING: Footnote [4] is not referenced.

These need to be fixed before we can switch to new way of building specs
as recomended by OpenStack Project Testing Interface:
https://governance.openstack.org/tc/reference/project-testing-interface.html#documentation

Change-Id: Ibe58c27303f49a72779f0d5ebdd52c001ee8b23c
Closes-Bug: 1810677
This commit is contained in:
Radoslaw Smigielski 2019-01-06 19:42:06 +01:00
parent 357c7940e2
commit 92f9e7b8df
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
specs/liberty/clone-image-in-glance-cinder-backend.rst
View File

@ -54,7 +54,7 @@ on creating a volume from an image:
On uploading a volume to an image:
* If image format is raw and image_upload_use_cinder_backend is enabled in
cinder.conf, clone the volume and register its location to the image.
cinder.conf, clone the volume and register its location to the image [2]_.
* If image_upload_use_internal_tenant is set to True, the cloned volume is
placed in the internal tenant.

10
specs/newton/discovering-system-capabilities.rst
View File

@ -123,7 +123,7 @@ Note that a cinder instance may implement a particular feature but may not
allow a particular user to access the same. So, the capabilities API
should not only consider whether the service implements the particular feature
but also if the current user is privileged to access the same. The "privilege"
information is already available in the policy.json file that maps different
information is already available in the policy.json [4]_ file that maps different
operations to the users that can access them. So, any capapbility API
implementation must make use of this file.
@ -134,10 +134,10 @@ replication feature, it could be statically set when the volume type is
created or it could be fetched from the driver somehow.
It is not possible to implement the capabilities API based solely on the info
in the policy.json file as the policy file does not allow defining rules per
resource. For example, we can allow replication operation for all users but we
cannot constrain it to a specific volume type (which is deal breaker since not
all volume types support replication).
in the policy.json [4]_ file as the policy file does not allow defining rules
per resource. For example, we can allow replication operation for all users
but we cannot constrain it to a specific volume type (which is deal breaker
since not all volume types support replication).
It is easy to see that all capabilities APIs should be public, i.e. accessible
by any user.