Fix indentation in docs

This commit removes weird indentations in docs.

Change-Id: I82dd98d9fd9a7bf4ff73a808f59651813ac5ec37
This commit is contained in:
Masayuki Igawa 2017-11-27 15:24:31 +09:00
parent 486a765075
commit c3daf02848
No known key found for this signature in database
GPG Key ID: 290F53EDC899BF89
5 changed files with 239 additions and 238 deletions

View File

@ -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 <version>
OpenStack-API-Version: volume <version>
where ``<version>`` is any valid api version for this API.
where ``<version>`` 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/<project_id>/manageable_volumes
- os-snapshot-manage => /v3/<project_id>/manageable_snapshots
Adds the following resources that were previously in extensions:
- os-volume-manage => /v3/<project_id>/manageable_volumes
- os-snapshot-manage => /v3/<project_id>/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 <https://developer.openstack.org/api-ref/block-storage/v3/index.html#attachments>`__
for details.
Added new attachment APIs. See the
`API reference <https://developer.openstack.org/api-ref/block-storage/v3/index.html#attachments>`__
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 <https://developer.openstack.org/api-ref/block-storage/v3/index.html#complete-attachment>`__
for details.
Support attachment completion. See the
`API reference <https://developer.openstack.org/api-ref/block-storage/v3/index.html#complete-attachment>`__
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.

View File

@ -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.

View File

@ -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 <class_name> <class_specs: bw=#, iops=#>
cinder qos-create <class_name> <class_specs: bw=#, iops=#>
2. Create a type:
2. Create a type:
.. code-block:: console
.. code-block:: console
cinder type-create type_<qos_class_name>
cinder type-create type_<qos_class_name>
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 <qos uuid> <type uuid>
cinder qos-associate <qos uuid> <type uuid>
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 <type_name or UUID> set QoS_support=True
cinder type-key <type_name or UUID> set QoS_support=True
5. Create a volume:
5. Create a volume:
.. code-block:: console
.. code-block:: console
cinder create 1 --volume-type <type_name>
cinder create 1 --volume-type <type_name>

View File

@ -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

View File

@ -193,21 +193,21 @@ Install and configure components
`example architecture <https://docs.openstack.org/install-guide/overview.html#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: