openstack/cinder-specs
Code Issues Proposed changes

Fix spec format errors

Browse Source 
Apparently in the window between switching from Jenkins to Zuul, some
specs that were merged by zuul contained some format errors that
Jenkins tests for but zuul does not. So now that we've switched back
to Jenkins, and new specs trying to merge are getting test failures
due to these other specs.

This addresses the failure seen as well as a few other doc8 issues
pointed out in case they cause issues as well.

Change-Id: I92554c5481417e5d4e0cc931a1f6efdbee9b8733
This commit is contained in:
Sean McGinnis 2017-10-04 07:30:36 -05:00
parent 33c7d806e2
commit e7b8d4bb01
4 changed files with 15 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
specs/queens/add-shared-targets-to-volume-ref.rst
View File

@ -20,8 +20,8 @@ For example, a device utilizing shared targets, may have a single iSCSI
connection shared for multiple volumes attached to a Nova compute node.
This can be troublesome because extra care needs to be taken by consumers to
make sure that the target it's not being used by another volumes on a system when
a delete/detach call is made.
make sure that the target it's not being used by another volumes on a system
when a delete/detach call is made.
Problem description
===================
@ -48,8 +48,8 @@ This improves the existing use case of detaching volumes correctly and
efficiently. The basic condition is that you have a device that utilizes
shared-targets, and you have a single volume (V-A) from that device attached to
a compute node. A user issues a detach call and at the same time another user
issues an attach of a different volume (V-B) from the same backend that will land on
the same compute node.
issues an attach of a different volume (V-B) from the same backend that will
land on the same compute node.
It's possible that the connection response for V-B is completed under the
assumption that the target exists (due to V-B) but then the V-A detach process
@ -125,6 +125,7 @@ API calls, however it does add additional fields to the Volume Get response.
When the appropriate micro-version is selected, we'll add two additional fields
to the detailed volume response view:
shared_targets
backend_name

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

@ -147,7 +147,7 @@ Work Items
Dependencies
============
Depends on generic backup implementation `[4]`_
Depends on generic backup implementation `[1]`_
Testing
=======

2
specs/queens/report-backend-state-in-service-list.rst
View File

@ -65,7 +65,7 @@ REST API impact
Add backend_state: up/down into response body of service list and also need
a microversions for this feature:
*GET /v3/{project_id}/os-services
* GET /v3/{project_id}/os-services
RESP BODY: {"services": [{"host": "host@backend1",
...,

16
specs/queens/transfer-snapshots-with-volumes.rst
View File

@ -65,16 +65,16 @@ Add a new field "with_snapshots(boolean)" in transfer model.
REST API impact
---------------
*New microversion in Cinder API.
* New microversion in Cinder API.
*Add an optional argumet "no_snapshots"::
* Add an optional argumet "no_snapshots"::
POST /v3/{project_id}/os-volume-transfer
RESP BODY: {"transfer": {
...
no_snapshots: [True/False],
}
}
POST /v3/{project_id}/os-volume-transfer
RESP BODY: {"transfer": {
...
no_snapshots: [True/False],
}
}
Security impact