From e7b8d4bb012f18874be7c3fa6fa328e4e5184095 Mon Sep 17 00:00:00 2001 From: Sean McGinnis Date: Wed, 4 Oct 2017 07:30:36 -0500 Subject: [PATCH] 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 --- .../queens/add-shared-targets-to-volume-ref.rst | 9 +++++---- specs/queens/create-volume-from-backup.rst | 2 +- .../report-backend-state-in-service-list.rst | 2 +- specs/queens/transfer-snapshots-with-volumes.rst | 16 ++++++++-------- 4 files changed, 15 insertions(+), 14 deletions(-) diff --git a/specs/queens/add-shared-targets-to-volume-ref.rst b/specs/queens/add-shared-targets-to-volume-ref.rst index 96f9a8af..ade679d9 100644 --- a/specs/queens/add-shared-targets-to-volume-ref.rst +++ b/specs/queens/add-shared-targets-to-volume-ref.rst @@ -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 diff --git a/specs/queens/create-volume-from-backup.rst b/specs/queens/create-volume-from-backup.rst index e7ca9d7c..ca22c521 100644 --- a/specs/queens/create-volume-from-backup.rst +++ b/specs/queens/create-volume-from-backup.rst @@ -147,7 +147,7 @@ Work Items Dependencies ============ -Depends on generic backup implementation `[4]`_ +Depends on generic backup implementation `[1]`_ Testing ======= diff --git a/specs/queens/report-backend-state-in-service-list.rst b/specs/queens/report-backend-state-in-service-list.rst index 7b5541b0..cfe6bb1d 100644 --- a/specs/queens/report-backend-state-in-service-list.rst +++ b/specs/queens/report-backend-state-in-service-list.rst @@ -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", ..., diff --git a/specs/queens/transfer-snapshots-with-volumes.rst b/specs/queens/transfer-snapshots-with-volumes.rst index 943ff91e..3982d6a2 100644 --- a/specs/queens/transfer-snapshots-with-volumes.rst +++ b/specs/queens/transfer-snapshots-with-volumes.rst @@ -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