Fix spec format errors
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:
parent
33c7d806e2
commit
e7b8d4bb01
@ -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
|
||||
|
||||
|
@ -147,7 +147,7 @@ Work Items
|
||||
Dependencies
|
||||
============
|
||||
|
||||
Depends on generic backup implementation `[4]`_
|
||||
Depends on generic backup implementation `[1]`_
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
@ -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",
|
||||
...,
|
||||
|
@ -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
|
||||
|
Loading…
x
Reference in New Issue
Block a user