Fix indentation in docs
This commit removes weird indentations in docs. Change-Id: I82dd98d9fd9a7bf4ff73a808f59651813ac5ec37
This commit is contained in:
parent
486a765075
commit
c3daf02848
@ -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.
|
||||
|
@ -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.
|
||||
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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
|
||||
|
||||
|
@ -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:
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user