Fix code-block JSON format issues

Sphinx 2.0 is more strict on enforcing proper format for the specified
code type. This resulted in a few warnings due to JSON code blocks not
being valid JSON. This cleans up a few cases that were not properly
formatted.

Closes-bug: #1822891

Change-Id: Id6fa50b759add5d2286b98f1752a7ff92bf0515d
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This commit is contained in:
Sean McGinnis 2019-04-02 17:04:53 -05:00
parent 1dec92ed8f
commit e27d781455
No known key found for this signature in database
GPG Key ID: CE7EE4BFAF8D70C8
2 changed files with 39 additions and 39 deletions

View File

@ -144,7 +144,7 @@ class AttachmentsController(wsgi.Controller):
"connector":
{
"initiator": "iqn.1993-08.org.debian:01:cad181614cec",
"ip":"192.168.1.20",
"ip": "192.168.1.20",
"platform": "x86_64",
"host": "tempest-1",
"os_type": "linux2",
@ -215,13 +215,13 @@ class AttachmentsController(wsgi.Controller):
"connector":
{
"initiator": "iqn.1993-08.org.debian:01:cad181614cec",
"ip":"192.168.1.20",
"ip": "192.168.1.20",
"platform": "x86_64",
"host": "tempest-1",
"os_type": "linux2",
"multipath": False,
"multipath": false,
"mountpoint": "/dev/vdb",
"mode": None|"rw"|"ro",
"mode": "None|rw|ro"
}
}
}

View File

@ -1743,40 +1743,42 @@ class VolumeManager(manager.CleanableManager,
This method calls the driver initialize_connection and returns
it to the caller. The connector parameter is a dictionary with
information about the host that will connect to the volume in the
following format::
following format:
.. code:: json
.. code:: json
{
'ip': ip,
'initiator': initiator,
}
{
"ip": "<ip>",
"initiator": "<initiator>"
}
ip: the ip address of the connecting machine
ip:
the ip address of the connecting machine
initiator: the iscsi initiator name of the connecting machine.
This can be None if the connecting machine does not support iscsi
connections.
initiator:
the iscsi initiator name of the connecting machine. This can be
None if the connecting machine does not support iscsi connections.
driver is responsible for doing any necessary security setup and
returning a connection_info dictionary in the following format::
returning a connection_info dictionary in the following format:
.. code:: json
.. code:: json
{
'driver_volume_type': driver_volume_type,
'data': data,
}
{
"driver_volume_type": "<driver_volume_type>",
"data": "<data>"
}
driver_volume_type: a string to identify the type of volume. This
can be used by the calling code to determine the
strategy for connecting to the volume. This could
be 'iscsi', 'rbd', 'sheepdog', etc.
driver_volume_type:
a string to identify the type of volume. This can be used by the
calling code to determine the strategy for connecting to the
volume. This could be 'iscsi', 'rbd', 'sheepdog', etc.
data:
this is the data that the calling code will use to connect to the
volume. Keep in mind that this will be serialized to json in
various places, so it should not contain any non-json data types.
data: this is the data that the calling code will use to connect
to the volume. Keep in mind that this will be serialized to
json in various places, so it should not contain any non-json
data types.
"""
# NOTE(flaper87): Verify the driver is enabled
# before going forward. The exception will be caught
@ -4921,31 +4923,29 @@ class VolumeManager(manager.CleanableManager,
.. code:: json
{
'replication_targets': [
"replication_targets": [
{
'backend_id': 'vendor-id-1',
'unique_key': 'val1',
......
"backend_id": "vendor-id-1",
"unique_key": "val1"
},
{
'backend_id': 'vendor-id-2',
'unique_key': 'val2',
......
"backend_id": "vendor-id-2",
"unique_key": "val2"
}
]
}
Response example for non-admin:
.. code json
.. code:: json
{
'replication_targets': [
"replication_targets": [
{
'backend_id': 'vendor-id-1'
"backend_id": "vendor-id-1"
},
{
'backend_id': 'vendor-id-2'
"backend_id": "vendor-id-2"
}
]
}