openstack
/
cinder
Code Issues Proposed changes

[doc] Update markups of options in capacity-based-qos 

This commit updates markups of the options in the capacity-based-qos
document. The original markup is "`" which is rendered as italic in our
document but it's different from the others. It should be better to keep
the consistency to avoid confusion in our doc.

Change-Id: I5dc76bb850309936f039d91dee986f4f7de81e07
This commit is contained in:
Masayuki Igawa 2022-04-26 14:52:11 +09:00
parent 3e068b5ce0
commit aa0b239fb0
1 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
doc/source/admin/capacity-based-qos.rst
View File

@ -26,15 +26,15 @@ which values should be fairly self explanatory:
For dynamic IOPS per volume.
* `read_iops_sec_per_gb`
* `write_iops_sec_per_gb`
* `total_iops_sec_per_gb`
* ``read_iops_sec_per_gb``
* ``write_iops_sec_per_gb``
* ``total_iops_sec_per_gb``
For dynamic bandwidth per volume.
* `read_bytes_sec_per_gb`
* `write_bytes_sec_per_gb`
* `total_bytes_sec_per_gb`
* ``read_bytes_sec_per_gb``
* ``write_bytes_sec_per_gb``
* ``total_bytes_sec_per_gb``
In addition, there are 6 more options which allow you to control the minimum
possible value. This can be useful in cases where a user creates a volume that
@ -42,19 +42,19 @@ is very small and ends up with an unusable volume because of performance.
For minimum IOPS per volume.
* `read_iops_sec_per_gb_min`
* `write_iops_sec_per_gb_min`
* `total_iops_sec_per_gb_min`
* ``read_iops_sec_per_gb_min``
* ``write_iops_sec_per_gb_min``
* ``total_iops_sec_per_gb_min``
For minimum bandwidth per volume.
* `read_bytes_sec_per_gb_min`
* `write_bytes_sec_per_gb_min`
* `total_bytes_sec_per_gb_min`
* ``read_bytes_sec_per_gb_min``
* ``write_bytes_sec_per_gb_min``
* ``total_bytes_sec_per_gb_min``
Capacity based options might be used in conjunction with basic options,
like `*_sec_max`, in order to set upper limits for volumes. This may be useful
for large volumes, which may consume all storage performance.
like ``*_sec_max``, in order to set upper limits for volumes. This may be
useful for large volumes, which may consume all storage performance.
For example, in order to create a QoS with 30 IOPs total writes per GB and
a throughput of 1MB per GB, you might use the Cinder client in the following
@ -75,7 +75,7 @@ way:
+----------+--------------------------------------+
Once this is done, you can associate this QoS with a volume type by using
the `qos-associate` Cinder client command.
the ``qos-associate`` Cinder client command.
.. code-block:: console
@ -84,4 +84,4 @@ the `qos-associate` Cinder client command.
You can now create a new volume and attempt to attach it to a consumer such
as Nova. If you login to a Nova compute host, you'll be able to see the
new calculated limits when checking the XML definition of the virtual machine
with `virsh dumpxml`.
with ``virsh dumpxml``.