From c3daf028489e9dc7c8a527dcdb0e2a1cf668c489 Mon Sep 17 00:00:00 2001 From: Masayuki Igawa Date: Mon, 27 Nov 2017 15:24:31 +0900 Subject: [PATCH] Fix indentation in docs This commit removes weird indentations in docs. Change-Id: I82dd98d9fd9a7bf4ff73a808f59651813ac5ec37 --- .../openstack/rest_api_version_history.rst | 403 +++++++++--------- .../block-storage/drivers/hpe-3par-driver.rst | 10 +- .../drivers/ibm-storage-volume-driver.rst | 38 +- .../install/cinder-storage-install-obs.rst | 2 +- .../install/cinder-storage-install-ubuntu.rst | 24 +- 5 files changed, 239 insertions(+), 238 deletions(-) diff --git a/cinder/api/openstack/rest_api_version_history.rst b/cinder/api/openstack/rest_api_version_history.rst index 20d37ad569b..25d4aa00535 100644 --- a/cinder/api/openstack/rest_api_version_history.rst +++ b/cinder/api/openstack/rest_api_version_history.rst @@ -8,384 +8,385 @@ user documentation. 3.0 (Maximum in Mitaka) ----------------------- - The 3.0 Cinder API includes all v2 core APIs existing prior to - the introduction of microversions. The /v3 URL is used to call - 3.0 APIs. - This is the initial version of the Cinder API which supports - microversions. +The 3.0 Cinder API includes all v2 core APIs existing prior to +the introduction of microversions. The /v3 URL is used to call +3.0 APIs. +This is the initial version of the Cinder API which supports +microversions. - A user can specify a header in the API request:: +A user can specify a header in the API request:: - OpenStack-API-Version: volume + OpenStack-API-Version: volume - where ```` is any valid api version for this API. +where ```` is any valid api version for this API. - If no version is specified then the API will behave as if version 3.0 - was requested. +If no version is specified then the API will behave as if version 3.0 +was requested. - The only API change in version 3.0 is versions, i.e. - GET http://localhost:8786/, which now returns information about - 3.0 and later versions and their respective /v3 endpoints. +The only API change in version 3.0 is versions, i.e. +GET http://localhost:8786/, which now returns information about +3.0 and later versions and their respective /v3 endpoints. - All other 3.0 APIs are functionally identical to version 2.0. +All other 3.0 APIs are functionally identical to version 2.0. 3.1 --- - Added the parameters ``protected`` and ``visibility`` to - _volume_upload_image requests. +Added the parameters ``protected`` and ``visibility`` to +_volume_upload_image requests. 3.2 --- - Change in return value of 'GET API request' for fetching cinder volume - list on the basis of 'bootable' status of volume as filter. +Change in return value of 'GET API request' for fetching cinder volume +list on the basis of 'bootable' status of volume as filter. - Before V3.2, 'GET API request' to fetch volume list returns non-bootable - volumes if bootable filter value is any of the false or False. - For any other value provided to this filter, it always returns - bootable volume list. +Before V3.2, 'GET API request' to fetch volume list returns non-bootable +volumes if bootable filter value is any of the false or False. +For any other value provided to this filter, it always returns +bootable volume list. - But in V3.2, this behavior is updated. - In V3.2, bootable volume list will be returned for any of the - 'T/True/1/true' bootable filter values only. - Non-bootable volume list will be returned for any of 'F/False/0/false' - bootable filter values. - But for any other values passed for bootable filter, it will return - "Invalid input received: bootable={filter value}' error. +But in V3.2, this behavior is updated. +In V3.2, bootable volume list will be returned for any of the +'T/True/1/true' bootable filter values only. +Non-bootable volume list will be returned for any of 'F/False/0/false' +bootable filter values. +But for any other values passed for bootable filter, it will return +"Invalid input received: bootable={filter value}' error. 3.3 --- - Added /messages API. +Added /messages API. 3.4 --- - Added the filter parameters ``glance_metadata`` to - list/detail volumes requests. +Added the filter parameters ``glance_metadata`` to +list/detail volumes requests. 3.5 --- - Added pagination support to /messages API +Added pagination support to /messages API 3.6 --- - Allowed to set empty description and empty name for consistency - group in consisgroup-update operation. +Allowed to set empty description and empty name for consistency +group in consisgroup-update operation. 3.7 --- - Added ``cluster_name`` field to service list/detail. +Added ``cluster_name`` field to service list/detail. - Added /clusters endpoint to list/show/update clusters. +Added /clusters endpoint to list/show/update clusters. - Show endpoint requires the cluster name and optionally the binary as a URL - parameter (default is "cinder-volume"). Returns: +Show endpoint requires the cluster name and optionally the binary as a URL +parameter (default is "cinder-volume"). Returns: - .. code-block:: json +.. code-block:: json - { - "cluster": { - "created_at": "", - "disabled_reason": null, - "last_heartbeat": "", - "name": "cluster_name", - "num_down_hosts": 4, - "num_hosts": 2, - "state": "up", - "status": "enabled", - "updated_at": "" - } - } + { + "cluster": { + "created_at": "", + "disabled_reason": null, + "last_heartbeat": "", + "name": "cluster_name", + "num_down_hosts": 4, + "num_hosts": 2, + "state": "up", + "status": "enabled", + "updated_at": "" + } + } - Update endpoint allows enabling and disabling a cluster in a similar way to - service's update endpoint, but in the body we must specify the name and - optionally the binary ("cinder-volume" is the default) and the disabled - reason. Returns: +Update endpoint allows enabling and disabling a cluster in a similar way to +service's update endpoint, but in the body we must specify the name and +optionally the binary ("cinder-volume" is the default) and the disabled +reason. Returns: - .. code-block:: json +.. code-block:: json - { - "cluster": { - "name": "cluster_name", - "state": "up", - "status": "enabled", - "disabled_reason": null - } - } + { + "cluster": { + "name": "cluster_name", + "state": "up", + "status": "enabled", + "disabled_reason": null + } + } - Index and detail accept filtering by `name`, `binary`, `disabled`, - `num_hosts` , `num_down_hosts`, and up/down status (`is_up`) as URL - parameters. +Index and detail accept filtering by `name`, `binary`, `disabled`, +`num_hosts` , `num_down_hosts`, and up/down status (`is_up`) as URL +parameters. - Index endpoint returns: +Index endpoint returns: - .. code-block:: json +.. code-block:: json - { - "clusters": [ - { - "name": "cluster_name", - "state": "up", - "status": "enabled" - } - ] - } + { + "clusters": [ + { + "name": "cluster_name", + "state": "up", + "status": "enabled" + } + ] + } - Detail endpoint returns: +Detail endpoint returns: - .. code-block:: json +.. code-block:: json - { - "clusters": [ - { - "created_at": "", - "disabled_reason": null, - "last_heartbeat": "", - "name": "cluster_name", - "num_down_hosts": 4, - "num_hosts": 2, - "state": "up", - "status": "enabled", - "updated_at": "" - } - ] - } + { + "clusters": [ + { + "created_at": "", + "disabled_reason": null, + "last_heartbeat": "", + "name": "cluster_name", + "num_down_hosts": 4, + "num_hosts": 2, + "state": "up", + "status": "enabled", + "updated_at": "" + } + ] + } 3.8 --- - Adds the following resources that were previously in extensions: - - os-volume-manage => /v3//manageable_volumes - - os-snapshot-manage => /v3//manageable_snapshots +Adds the following resources that were previously in extensions: + +- os-volume-manage => /v3//manageable_volumes +- os-snapshot-manage => /v3//manageable_snapshots 3.9 --- - Added backup update interface to change name and description. - Returns: +Added backup update interface to change name and description. +Returns: - .. code-block:: json +.. code-block:: json - { - "backup": { - "id": "backup_id", - "name": "backup_name", - "links": "backup_link" - } - } + { + "backup": { + "id": "backup_id", + "name": "backup_name", + "links": "backup_link" + } + } 3.10 ---- - Added the filter parameters ``group_id`` to - list/detail volumes requests. +Added the filter parameters ``group_id`` to +list/detail volumes requests. 3.11 ---- - Added group types and group specs APIs. +Added group types and group specs APIs. 3.12 ---- - Added volumes/summary API. +Added volumes/summary API. 3.13 ---- - Added create/delete/update/list/show APIs for generic volume groups. +Added create/delete/update/list/show APIs for generic volume groups. 3.14 ---- - Added group snapshots and create group from src APIs. +Added group snapshots and create group from src APIs. 3.15 (Maximum in Newton) ------------------------ - Added injecting the response's `Etag` header to avoid the lost update - problem with volume metadata. +Added injecting the response's `Etag` header to avoid the lost update +problem with volume metadata. 3.16 ---- - os-migrate_volume now accepts ``cluster`` parameter when we want to migrate a - volume to a cluster. If we pass the ``host`` parameter for a volume that is - in a cluster, the request will be sent to the cluster as if we had requested - that specific cluster. Only ``host`` or ``cluster`` can be provided. +os-migrate_volume now accepts ``cluster`` parameter when we want to migrate a +volume to a cluster. If we pass the ``host`` parameter for a volume that is +in a cluster, the request will be sent to the cluster as if we had requested +that specific cluster. Only ``host`` or ``cluster`` can be provided. - Creating a managed volume also supports the cluster parameter. +Creating a managed volume also supports the cluster parameter. 3.17 ---- - os-snapshot-manage and os-volume-manage now support ``cluster`` parameter on - listings (summary and detailed). Both location parameters, ``cluster`` and - ``host`` are exclusive and only one should be provided. +os-snapshot-manage and os-volume-manage now support ``cluster`` parameter on +listings (summary and detailed). Both location parameters, ``cluster`` and +``host`` are exclusive and only one should be provided. 3.18 ---- - Added backup project attribute. +Added backup project attribute. 3.19 ---- - Added reset status actions 'reset_status' to group snapshot. +Added reset status actions 'reset_status' to group snapshot. 3.20 ---- - Added reset status actions 'reset_status' to generic volume group. +Added reset status actions 'reset_status' to generic volume group. 3.21 ---- - Show provider_id in detailed view of a volume for admin. +Show provider_id in detailed view of a volume for admin. 3.22 ---- - Added support to filter snapshot list based on metadata of snapshot. +Added support to filter snapshot list based on metadata of snapshot. 3.23 ---- - Allow passing force parameter to volume delete. +Allow passing force parameter to volume delete. 3.24 ---- - New API endpoint /workers/cleanup allows triggering cleanup for cinder-volume - services. Meant for cleaning ongoing operations from failed nodes. +New API endpoint /workers/cleanup allows triggering cleanup for cinder-volume +services. Meant for cleaning ongoing operations from failed nodes. - The cleanup will be performed by other services belonging to the same - cluster, so at least one of them must be up to be able to do the cleanup. +The cleanup will be performed by other services belonging to the same +cluster, so at least one of them must be up to be able to do the cleanup. - Cleanup cannot be triggered during a cloud upgrade. +Cleanup cannot be triggered during a cloud upgrade. - If no arguments are provided cleanup will try to issue a clean message for - all nodes that are down, but we can restrict which nodes we want to be - cleaned using parameters ``service_id``, ``cluster_name``, ``host``, - ``binary``, and ``disabled``. +If no arguments are provided cleanup will try to issue a clean message for +all nodes that are down, but we can restrict which nodes we want to be +cleaned using parameters ``service_id``, ``cluster_name``, ``host``, +``binary``, and ``disabled``. - Cleaning specific resources is also possible using ``resource_type`` and - ``resource_id`` parameters. +Cleaning specific resources is also possible using ``resource_type`` and +``resource_id`` parameters. - We can even force cleanup on nodes that are up with ``is_up``, but that's - not recommended and should only used if you know what you are doing. For - example if you know a specific cinder-volume is down even though it's still - not being reported as down when listing the services and you know the cluster - has at least another service to do the cleanup. +We can even force cleanup on nodes that are up with ``is_up``, but that's +not recommended and should only used if you know what you are doing. For +example if you know a specific cinder-volume is down even though it's still +not being reported as down when listing the services and you know the cluster +has at least another service to do the cleanup. - API will return a dictionary with 2 lists, one with services that have been - issued a cleanup request (``cleaning`` key) and the other with services - that cannot be cleaned right now because there is no alternative service to - do the cleanup in that cluster (``unavailable`` key). +API will return a dictionary with 2 lists, one with services that have been +issued a cleanup request (``cleaning`` key) and the other with services +that cannot be cleaned right now because there is no alternative service to +do the cleanup in that cluster (``unavailable`` key). - Data returned for each service element in these two lists consist of the - ``id``, ``host``, ``binary``, and ``cluster_name``. These are not the - services that will be performing the cleanup, but the services that will be - cleaned up or couldn't be cleaned up. +Data returned for each service element in these two lists consist of the +``id``, ``host``, ``binary``, and ``cluster_name``. These are not the +services that will be performing the cleanup, but the services that will be +cleaned up or couldn't be cleaned up. 3.25 ---- - Add ``volumes`` field to group list/detail and group show. +Add ``volumes`` field to group list/detail and group show. 3.26 ---- - - New ``failover`` action equivalent to ``failover_host``, but accepting - ``cluster`` parameter as well as the ``host`` cluster that - ``failover_host`` accepts. +- New ``failover`` action equivalent to ``failover_host``, but accepting + ``cluster`` parameter as well as the ``host`` cluster that + ``failover_host`` accepts. - - ``freeze`` and ``thaw`` actions accept ``cluster`` parameter. +- ``freeze`` and ``thaw`` actions accept ``cluster`` parameter. - - Cluster listing accepts ``replication_status``, ``frozen`` and - ``active_backend_id`` as filters, and returns additional fields for each - cluster: ``replication_status``, ``frozen``, ``active_backend_id``. +- Cluster listing accepts ``replication_status``, ``frozen`` and + ``active_backend_id`` as filters, and returns additional fields for each + cluster: ``replication_status``, ``frozen``, ``active_backend_id``. 3.27 (Maximum in Ocata) ----------------------- - Added new attachment APIs. See the - `API reference `__ - for details. +Added new attachment APIs. See the +`API reference `__ +for details. 3.28 ---- - Add filters support to get_pools +Add filters support to get_pools 3.29 ---- - Add filter, sorter and pagination support in group snapshot. +Add filter, sorter and pagination support in group snapshot. 3.30 ---- - Support sort snapshots with "name". +Support sort snapshots with "name". 3.31 ---- - Add support for configure resource query filters. +Add support for configure resource query filters. 3.32 ---- - Added ``set-log`` and ``get-log`` service actions. +Added ``set-log`` and ``get-log`` service actions. 3.33 ---- - Add ``resource_filters`` API to retrieve configured resource filters. +Add ``resource_filters`` API to retrieve configured resource filters. 3.34 ---- - Add like filter support in ``volume``, ``backup``, ``snapshot``, ``message``, - ``attachment``, ``group`` and ``group-snapshot`` list APIs. +Add like filter support in ``volume``, ``backup``, ``snapshot``, ``message``, +``attachment``, ``group`` and ``group-snapshot`` list APIs. 3.35 ---- - Add ``volume-type`` filter to Get-Pools API. +Add ``volume-type`` filter to Get-Pools API. 3.36 ---- - Add metadata to volumes/summary response body. +Add metadata to volumes/summary response body. 3.37 ---- - Support sort backup by "name". +Support sort backup by "name". 3.38 ---- - Added enable_replication/disable_replication/failover_replication/ - list_replication_targets for replication groups (Tiramisu). +Added enable_replication/disable_replication/failover_replication/ +list_replication_targets for replication groups (Tiramisu). 3.39 ---- - Add ``project_id`` admin filters support to limits. +Add ``project_id`` admin filters support to limits. 3.40 ---- - Add volume revert to its latest snapshot support. +Add volume revert to its latest snapshot support. 3.41 ---- - Add ``user_id`` field to snapshot list/detail and snapshot show. +Add ``user_id`` field to snapshot list/detail and snapshot show. 3.42 ---- - Add ability to extend 'in-use' volume. User should be aware of the - whole environment before using this feature because it's dependent - on several external factors below: +Add ability to extend 'in-use' volume. User should be aware of the +whole environment before using this feature because it's dependent +on several external factors below: - 1. nova-compute version - needs to be the latest for Pike. - 2. only the libvirt compute driver supports this currently. - 3. only iscsi and fibre channel volume types are supported on the - nova side currently. +1. nova-compute version - needs to be the latest for Pike. +2. only the libvirt compute driver supports this currently. +3. only iscsi and fibre channel volume types are supported on the + nova side currently. - Administrator can disable this ability by updating the - ``volume:extend_attached_volume`` policy rule. Extend of a resered - Volume is NOT allowed. +Administrator can disable this ability by updating the +``volume:extend_attached_volume`` policy rule. Extend of a resered +Volume is NOT allowed. 3.43 (Maximum in Pike) ---------------------- - Support backup CRUD with metadata. +Support backup CRUD with metadata. 3.44 ---- - Support attachment completion. See the - `API reference `__ - for details. +Support attachment completion. See the +`API reference `__ +for details. 3.45 ---- - Add ``count`` field to volume, backup and snapshot list and detail APIs. +Add ``count`` field to volume, backup and snapshot list and detail APIs. 3.46 ---- - Support create volume by Nova specific image (0 size image). +Support create volume by Nova specific image (0 size image). 3.47 ---- - Support create volume from backup. +Support create volume from backup. 3.48 ---- - Add ``shared_targets`` and ``service_uuid`` fields to volume. +Add ``shared_targets`` and ``service_uuid`` fields to volume. diff --git a/doc/source/configuration/block-storage/drivers/hpe-3par-driver.rst b/doc/source/configuration/block-storage/drivers/hpe-3par-driver.rst index 69d9de43be9..a06625dff57 100644 --- a/doc/source/configuration/block-storage/drivers/hpe-3par-driver.rst +++ b/doc/source/configuration/block-storage/drivers/hpe-3par-driver.rst @@ -245,12 +245,12 @@ the following requirements: Other restrictions and considerations for ``hpe3par:compression``: - - For a compressed volume, minimum volume size needed is 16 GB; otherwise - resulting volume will be created successfully but will not be a compressed volume. +- For a compressed volume, minimum volume size needed is 16 GB; otherwise + resulting volume will be created successfully but will not be a compressed volume. - - A full provisioned volume cannot be compressed, - if a compression is enabled and provisioning type requested is full, - the resulting volume defaults to thinly provisioned compressed volume. +- A full provisioned volume cannot be compressed, + if a compression is enabled and provisioning type requested is full, + the resulting volume defaults to thinly provisioned compressed volume. LDAP and AD authentication is now supported in the HPE 3PAR driver. diff --git a/doc/source/configuration/block-storage/drivers/ibm-storage-volume-driver.rst b/doc/source/configuration/block-storage/drivers/ibm-storage-volume-driver.rst index 2a0cedf69d5..7567a8d83ef 100644 --- a/doc/source/configuration/block-storage/drivers/ibm-storage-volume-driver.rst +++ b/doc/source/configuration/block-storage/drivers/ibm-storage-volume-driver.rst @@ -77,10 +77,10 @@ man-in-the-middle (MITM) attacks by following these rules: (``XIV-CA.pem``). The certificate files should be copied to one of the following directories: - * ``/etc/ssl/certs`` - * ``/etc/ssl/certs/xiv`` - * ``/etc/pki`` - * ``/etc/pki/xiv`` + * ``/etc/ssl/certs`` + * ``/etc/ssl/certs/xiv`` + * ``/etc/pki`` + * ``/etc/pki/xiv`` If you are using your own certificates, copy them to the same directories with the prefix "XIV" and in the ``.pem`` format. For example: XIV-my_cert.pem. @@ -197,33 +197,33 @@ QoS class types: To define a QoS class: - 1. Create the QoS class: +1. Create the QoS class: - .. code-block:: console + .. code-block:: console - cinder qos-create + cinder qos-create - 2. Create a type: +2. Create a type: - .. code-block:: console + .. code-block:: console - cinder type-create type_ + cinder type-create type_ - 3. Associate the QoS class with the type: +3. Associate the QoS class with the type: - .. code-block:: console + .. code-block:: console - cinder qos-associate + cinder qos-associate - 4. Announce that the type is supporting QoS: +4. Announce that the type is supporting QoS: - .. code-block:: console + .. code-block:: console - cinder type-key set QoS_support=True + cinder type-key set QoS_support=True - 5. Create a volume: +5. Create a volume: - .. code-block:: console + .. code-block:: console - cinder create 1 --volume-type + cinder create 1 --volume-type diff --git a/doc/source/install/cinder-storage-install-obs.rst b/doc/source/install/cinder-storage-install-obs.rst index 967146c823c..e0662b97e51 100644 --- a/doc/source/install/cinder-storage-install-obs.rst +++ b/doc/source/install/cinder-storage-install-obs.rst @@ -15,7 +15,7 @@ storage node, you must prepare the storage device. #. Install the LVM packages: - .. code-block:: console + .. code-block:: console # zypper install lvm2 diff --git a/doc/source/install/cinder-storage-install-ubuntu.rst b/doc/source/install/cinder-storage-install-ubuntu.rst index 08ee3e23927..2f486271119 100644 --- a/doc/source/install/cinder-storage-install-ubuntu.rst +++ b/doc/source/install/cinder-storage-install-ubuntu.rst @@ -193,21 +193,21 @@ Install and configure components `example architecture `_. - * In the ``[lvm]`` section, configure the LVM back end with the - LVM driver, ``cinder-volumes`` volume group, iSCSI protocol, - and appropriate iSCSI service: + * In the ``[lvm]`` section, configure the LVM back end with the + LVM driver, ``cinder-volumes`` volume group, iSCSI protocol, + and appropriate iSCSI service: - .. path /etc/cinder/cinder.conf - .. code-block:: ini + .. path /etc/cinder/cinder.conf + .. code-block:: ini - [lvm] - # ... - volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver - volume_group = cinder-volumes - iscsi_protocol = iscsi - iscsi_helper = tgtadm + [lvm] + # ... + volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver + volume_group = cinder-volumes + iscsi_protocol = iscsi + iscsi_helper = tgtadm - .. end + .. end * In the ``[DEFAULT]`` section, enable the LVM back end: