diff --git a/doc/user-guide-admin/source/analyzing-log-files-with-swift-cli.rst b/doc/user-guide-admin/source/analyzing-log-files-with-swift-cli.rst
index 420600ed62..9e33118117 100644
--- a/doc/user-guide-admin/source/analyzing-log-files-with-swift-cli.rst
+++ b/doc/user-guide-admin/source/analyzing-log-files-with-swift-cli.rst
@@ -6,10 +6,10 @@ Use the swift command-line client to analyze log files.
The swift client is simple to use, scalable, and flexible.
-Use the swift client ``-o`` or ``-output`` option to get short answers
-to questions about logs.
+Use the swift client :option:`-o` or :option:`-output` option to get
+short answers to questions about logs.
-You can use the ``-o`` or ``--output`` option with a single object
+You can use the :option:`-o` or :option:`--output` option with a single object
download to redirect the command output to a specific file or to STDOUT
(``-``). The ability to redirect the output to STDOUT enables you to
pipe (``|``) data without saving it to disk first.
@@ -18,80 +18,94 @@ Upload and analyze log files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. This example assumes that ``logtest`` directory contains the
- following log files::
+ following log files.
- 2010-11-16-21_access.log
- 2010-11-16-22_access.log
- 2010-11-15-21_access.log
- 2010-11-15-22_access.log
+ .. code-block:: console
+
+ 2010-11-16-21_access.log
+ 2010-11-16-22_access.log
+ 2010-11-15-21_access.log
+ 2010-11-15-22_access.log
- Each file uses the following line format::
+ Each file uses the following line format.
- Nov 15 21:53:52 lucid64 proxy-server - 127.0.0.1 15/Nov/2010/22/53/52 DELETE /v1/AUTH_cd4f57824deb4248a533f2c28bf156d3/2eefc05599d44df38a7f18b0b42ffedd HTTP/1.0 204 - \
+ .. code-block:: console
+
+ Nov 15 21:53:52 lucid64 proxy-server - 127.0.0.1 15/Nov/2010/22/53/52 DELETE /v1/AUTH_cd4f57824deb4248a533f2c28bf156d3/2eefc05599d44df38a7f18b0b42ffedd HTTP/1.0 204 - \
- test%3Atester%2CAUTH_tkcdab3c6296e249d7b7e2454ee57266ff - - - txaba5984c-aac7-460e-b04b-afc43f0c6571 - 0.0432
-#. Change into the ``logtest`` directory::
+#. Change into the ``logtest`` directory.
- $ cd logtest
+ .. code-block:: console
-#. Upload the log files into the ``logtest`` container::
+ $ cd logtest
- $ swift -A http://swift-auth.com:11000/v1.0 -U test:tester -K testing upload logtest *.log
+#. Upload the log files into the ``logtest`` container.
- .. code::
+ .. code-block:: console
- 2010-11-16-21_access.log
- 2010-11-16-22_access.log
- 2010-11-15-21_access.log
- 2010-11-15-22_access.log
+ $ swift -A http://swift-auth.com:11000/v1.0 -U test:tester -K testing upload logtest *.log
-#. Get statistics for the account::
+ .. code-block:: console
- $ swift -A http://swift-auth.com:11000/v1.0 -U test:tester -K testing \
- -q stat
+ 2010-11-16-21_access.log
+ 2010-11-16-22_access.log
+ 2010-11-15-21_access.log
+ 2010-11-15-22_access.log
- .. code::
+#. Get statistics for the account.
- Account: AUTH_cd4f57824deb4248a533f2c28bf156d3
- Containers: 1
- Objects: 4
- Bytes: 5888268
+ .. code-block:: console
-#. Get statistics for the logtest container::
+ $ swift -A http://swift-auth.com:11000/v1.0 -U test:tester -K testing \
+ -q stat
- $ swift -A http://swift-auth.com:11000/v1.0 -U test:tester -K testing \
- stat logtest
+ .. code-block:: console
- .. code::
+ Account: AUTH_cd4f57824deb4248a533f2c28bf156d3
+ Containers: 1
+ Objects: 4
+ Bytes: 5888268
- Account: AUTH_cd4f57824deb4248a533f2c28bf156d3
- Container: logtest
- Objects: 4
- Bytes: 5864468
- Read ACL:
- Write ACL:
+#. Get statistics for the ``logtest`` container.
-#. List all objects in the logtest container::
+ .. code-block:: console
- $ swift -A http:///swift-auth.com:11000/v1.0 -U test:tester -K testing \
- list logtest
+ $ swift -A http://swift-auth.com:11000/v1.0 -U test:tester -K testing \
+ stat logtest
- .. code::
+ .. code-block:: console
- 2010-11-15-21_access.log
- 2010-11-15-22_access.log
- 2010-11-16-21_access.log
- 2010-11-16-22_access.log
+ Account: AUTH_cd4f57824deb4248a533f2c28bf156d3
+ Container: logtest
+ Objects: 4
+ Bytes: 5864468
+ Read ACL:
+ Write ACL:
+
+#. List all objects in the logtest container.
+
+ .. code-block:: console
+
+ $ swift -A http:///swift-auth.com:11000/v1.0 -U test:tester -K testing \
+ list logtest
+
+ .. code-block:: console
+
+ 2010-11-15-21_access.log
+ 2010-11-15-22_access.log
+ 2010-11-16-21_access.log
+ 2010-11-16-22_access.log
Download and analyze an object
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-This example uses the ``-o`` option and a hyphen (``-``) to get
+This example uses the :option:`-o` option and a hyphen (``-``) to get
information about an object.
-Use the swift ``download`` command to download the object. On this
+Use the :command:`swift download` command to download the object. On this
command, stream the output to ``awk`` to break down requests by return
code and the date ``2200 on November 16th, 2010``.
@@ -102,13 +116,15 @@ After ``awk`` processes the output, it pipes it to ``sort`` and ``uniq
-c`` to sum up the number of occurrences for each request type and
return code combination.
-#. Download an object::
+#. Download an object.
- $ swift -A http://swift-auth.com:11000/v1.0 -U test:tester -K testing \
- download -o - logtest 2010-11-16-22_access.log | awk '{ print \
- $9"-"$12}' | sort | uniq -c
+ .. code-block:: console
- .. code::
+ $ swift -A http://swift-auth.com:11000/v1.0 -U test:tester -K testing \
+ download -o - logtest 2010-11-16-22_access.log | awk '{ print \
+ $9"-"$12}' | sort | uniq -c
+
+ .. code-block:: console
805 DELETE-204
12 DELETE-404
@@ -143,25 +159,25 @@ return code combination.
#. Discover how many PUT requests are in each log file.
- Use a bash for loop with awk and swift with the ``-o`` or
- ``--output`` option and a hyphen (``-``) to discover how many PUT
- requests are in each log file.
+ Use a bash for loop with awk and swift with the :option:`-o` or
+ :option:`--output` option and a hyphen (``-``) to discover how many
+ PUT requests are in each log file.
- Run the swift ``list`` command to list objects in the logtest
- container. Then, for each item in the list, run the swift ``download
- -o -`` command. Pipe the output into grep to filter the PUT requests.
- Finally, pipe into ``wc -l`` to count the lines.
+ Run the :command:`swift list` command to list objects in the logtest
+ container. Then, for each item in the list, run the
+ :command:`swift download -o -` command. Pipe the output into grep to
+ filter the PUT requests. Finally, pipe into ``wc -l`` to count the lines.
- .. code::
+ .. code-block:: console
$ for f in `swift -A http://swift-auth.com:11000/v1.0 -U test:tester \
- -K testing list logtest` ; \
+ -K testing list logtest` ; \
do echo -ne "PUTS - " ; swift -A \
http://swift-auth.com:11000/v1.0 -U test:tester \
-K testing download -o - logtest $f | grep PUT | wc -l ; \
done
- .. code::
+ .. code-block:: console
2010-11-15-21_access.log - PUTS - 402
2010-11-15-22_access.log - PUTS - 1091
@@ -170,23 +186,26 @@ return code combination.
#. List the object names that begin with a specified string.
-#. Run the swift ``list -p 2010-11-15`` command to list objects in the
- logtest container that begin with the ``2010-11-15`` string.
+#. Run the :command:`swift list -p 2010-11-15` command to list objects
+ in the logtest container that begin with the ``2010-11-15`` string.
-#. For each item in the list, run the swift **download -o -** command.
+#. For each item in the list, run the :command:`swift download -o -` command.
-#. Pipe the output to **grep** and **wc**. Use the **echo** command to
- display the object name::
+#. Pipe the output to :command:`grep` and :command:`wc`.
+ Use the :command:`echo` command to
+ display the object name.
+
+ .. code-block:: console
$ for f in `swift -A http://swift-auth.com:11000/v1.0 -U test:tester \
- -K testing list -p 2010-11-15 logtest` ; \
+ -K testing list -p 2010-11-15 logtest` ; \
do echo -ne "$f - PUTS - " ; swift -A \
http://127.0.0.1:11000/v1.0 -U test:tester \
-K testing download -o - logtest $f | grep PUT | wc -l ; \
done
- .. code::
+ .. code-block:: console
- 2010-11-15-21_access.log - PUTS - 402
- 2010-11-15-22_access.log - PUTS - 910
+ 2010-11-15-21_access.log - PUTS - 402
+ 2010-11-15-22_access.log - PUTS - 910
diff --git a/doc/user-guide-admin/source/cli_admin_manage_ip_addresses.rst b/doc/user-guide-admin/source/cli_admin_manage_ip_addresses.rst
index 1ce69b0e37..0386663ca0 100644
--- a/doc/user-guide-admin/source/cli_admin_manage_ip_addresses.rst
+++ b/doc/user-guide-admin/source/cli_admin_manage_ip_addresses.rst
@@ -11,8 +11,8 @@ Internet.
- By default, both administrative and end users can associate floating IP
addresses with projects and instances. You can change user permissions for
managing IP addresses by updating the ``/etc/nova/policy.json``
- file. For basic floating-IP procedures, refer to the *Manage IP
- Addresses* section in the `OpenStack End User Guide `_.
+ file. For basic floating-IP procedures, refer to the ``Manage IP
+ Addresses`` section in the `OpenStack End User Guide `_.
- For details on creating public networks using OpenStack Networking
(``neutron``), refer to the `OpenStack Cloud Administrator Guide
@@ -26,66 +26,81 @@ instances by end users.
List addresses for all projects
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To list all floating IP addresses for all projects, run::
- $ nova floating-ip-bulk-list
- +------------+---------------+---------------+--------+-----------+
- | project_id | address | instance_uuid | pool | interface |
- +------------+---------------+---------------+--------+-----------+
- | None | 172.24.4.225 | None | public | eth0 |
- | None | 172.24.4.226 | None | public | eth0 |
- | None | 172.24.4.227 | None | public | eth0 |
- | None | 172.24.4.228 | None | public | eth0 |
- | None | 172.24.4.229 | None | public | eth0 |
- | None | 172.24.4.230 | None | public | eth0 |
- | None | 172.24.4.231 | None | public | eth0 |
- | None | 172.24.4.232 | None | public | eth0 |
- | None | 172.24.4.233 | None | public | eth0 |
- | None | 172.24.4.234 | None | public | eth0 |
- | None | 172.24.4.235 | None | public | eth0 |
- | None | 172.24.4.236 | None | public | eth0 |
- | None | 172.24.4.237 | None | public | eth0 |
- | None | 172.24.4.238 | None | public | eth0 |
- | None | 192.168.253.1 | None | test | eth0 |
- | None | 192.168.253.2 | None | test | eth0 |
- | None | 192.168.253.3 | None | test | eth0 |
- | None | 192.168.253.4 | None | test | eth0 |
- | None | 192.168.253.5 | None | test | eth0 |
- | None | 192.168.253.6 | None | test | eth0 |
- +------------+---------------+---------------+--------+-----------+
+To list all floating IP addresses for all projects, run:
+
+.. code-block:: console
+
+ $ nova floating-ip-bulk-list
+ +------------+---------------+---------------+--------+-----------+
+ | project_id | address | instance_uuid | pool | interface |
+ +------------+---------------+---------------+--------+-----------+
+ | None | 172.24.4.225 | None | public | eth0 |
+ | None | 172.24.4.226 | None | public | eth0 |
+ | None | 172.24.4.227 | None | public | eth0 |
+ | None | 172.24.4.228 | None | public | eth0 |
+ | None | 172.24.4.229 | None | public | eth0 |
+ | None | 172.24.4.230 | None | public | eth0 |
+ | None | 172.24.4.231 | None | public | eth0 |
+ | None | 172.24.4.232 | None | public | eth0 |
+ | None | 172.24.4.233 | None | public | eth0 |
+ | None | 172.24.4.234 | None | public | eth0 |
+ | None | 172.24.4.235 | None | public | eth0 |
+ | None | 172.24.4.236 | None | public | eth0 |
+ | None | 172.24.4.237 | None | public | eth0 |
+ | None | 172.24.4.238 | None | public | eth0 |
+ | None | 192.168.253.1 | None | test | eth0 |
+ | None | 192.168.253.2 | None | test | eth0 |
+ | None | 192.168.253.3 | None | test | eth0 |
+ | None | 192.168.253.4 | None | test | eth0 |
+ | None | 192.168.253.5 | None | test | eth0 |
+ | None | 192.168.253.6 | None | test | eth0 |
+ +------------+---------------+---------------+--------+-----------+
Bulk create floating IP addresses
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To create a range of floating IP addresses, run::
-$ nova floating-ip-bulk-create [--pool POOL_NAME] [--interface INTERFACE] RANGE_TO_CREATE
+To create a range of floating IP addresses, run:
-For example::
+.. code-block:: console
- $ nova floating-ip-bulk-create --pool test 192.168.1.56/29
+ $ nova floating-ip-bulk-create [--pool POOL_NAME] [--interface INTERFACE] RANGE_TO_CREATE
-By default, **floating-ip-bulk-create** uses the
+For example:
+
+.. code-block:: console
+
+ $ nova floating-ip-bulk-create --pool test 192.168.1.56/29
+
+By default, ``floating-ip-bulk-create`` uses the
``public`` pool and ``eth0`` interface values.
-.. note:: You should use a range of free IP addresses that is correct for your
- network. If you are not sure, at least try to avoid the DHCP address
- range:
+.. note::
- - Pick a small range (/29 gives an 8 address range, 6 of
- which will be usable).
+ You should use a range of free IP addresses that is correct for your
+ network. If you are not sure, at least try to avoid the DHCP address
+ range:
- - Use **nmap** to check a range's availability. For example,
- 192.168.1.56/29 represents a small range of addresses
- (192.168.1.56-63, with 57-62 usable), and you could run the
- command **nmap -sn 192.168.1.56/29** to check whether the entire
- range is currently unused.
+ - Pick a small range (/29 gives an 8 address range, 6 of
+ which will be usable).
+
+ - Use :command:`nmap` to check a range's availability. For example,
+ 192.168.1.56/29 represents a small range of addresses
+ (192.168.1.56-63, with 57-62 usable), and you could run the
+ command :command:`nmap -sn 192.168.1.56/29` to check whether the entire
+ range is currently unused.
Bulk delete floating IP addresses
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To delete a range of floating IP addresses, run::
- $ nova floating-ip-bulk-delete RANGE_TO_DELETE
+To delete a range of floating IP addresses, run:
-For example::
+.. code-block:: console
- $ nova floating-ip-bulk-delete 192.168.1.56/29
+ $ nova floating-ip-bulk-delete RANGE_TO_DELETE
+
+For example:
+
+.. code-block:: console
+
+ $ nova floating-ip-bulk-delete 192.168.1.56/29
diff --git a/doc/user-guide-admin/source/cli_admin_manage_stacks.rst b/doc/user-guide-admin/source/cli_admin_manage_stacks.rst
index 9f8c5c2164..777a291164 100644
--- a/doc/user-guide-admin/source/cli_admin_manage_stacks.rst
+++ b/doc/user-guide-admin/source/cli_admin_manage_stacks.rst
@@ -27,7 +27,7 @@ As an administrator, you can also carry out stack functions
on behalf of your users. For example, to resume, suspend,
or delete a stack, run:
-.. code::
+.. code-block:: console
$ heat action-resume stackID
$ heat action-suspend stackID
diff --git a/doc/user-guide-admin/source/cli_cinder_quotas.rst b/doc/user-guide-admin/source/cli_cinder_quotas.rst
index a8045eb3c8..eecab60c3b 100644
--- a/doc/user-guide-admin/source/cli_cinder_quotas.rst
+++ b/doc/user-guide-admin/source/cli_cinder_quotas.rst
@@ -23,7 +23,7 @@ Administrative users can view Block Storage service quotas.
#. List the default quotas for all projects:
- .. code::
+ .. code-block:: console
$ cinder quota-defaults TENANT_ID
+-----------+-------+
@@ -34,13 +34,15 @@ Administrative users can view Block Storage service quotas.
| volumes | 10 |
+-----------+-------+
-#. View Block Storage service quotas for a project::
+#. View Block Storage service quotas for a project.
+
+ .. code-block:: console
$ cinder quota-show TENANT_NAME
For example:
- .. code::
+ .. code-block:: console
$ cinder quota-show tenant01
+-----------+-------+
@@ -53,7 +55,7 @@ Administrative users can view Block Storage service quotas.
#. Show the current usage of a per-tenant quota:
- .. code::
+ .. code-block:: console
$ cinder quota-usage tenantID
+-----------+--------+----------+-------+
@@ -70,28 +72,34 @@ Edit and update Block Storage service quotas
Administrative users can edit and update Block Storage
service quotas.
-#. Clear per-tenant quota limits::
+#. Clear per-tenant quota limits.
+
+ .. code-block:: console
$ cinder quota-delete tenantID
#. To update a default value for a new project,
update the property in the :guilabel:`cinder.quota`
- section of the :file:`/etc/cinder/cinder.conf` file.
+ section of the ``/etc/cinder/cinder.conf`` file.
For more information, see the `Block Storage
Configuration Reference `_.
#. To update Block Storage service quotas, place
- the tenant ID in a variable::
+ the tenant ID in a variable.
+
+ .. code-block:: console
$ tenant=$(openstack project show -f value -c id tenantName)
-#. Update a particular quota value::
+#. Update a particular quota value.
+
+ .. code-block:: console
$ cinder quota-update --quotaName NewValue tenantID
For example:
- .. code::
+ .. code-block:: console
$ cinder quota-update --volumes 15 $tenant
$ cinder quota-show tenant01
@@ -103,14 +111,18 @@ service quotas.
| volumes | 15 |
+-----------+-------+
-#. Clear per-tenant quota limits::
+#. Clear per-tenant quota limits.
+
+ .. code-block:: console
$ cinder quota-delete tenantID
Remove a service
~~~~~~~~~~~~~~~~
-#. Determine the binary and host of the service you want to remove::
+#. Determine the binary and host of the service you want to remove.
+
+ .. code-block:: console
$ cinder service-list
+------------------+----------------------+------+---------+-------+----------------------------+-----------------+
@@ -120,10 +132,14 @@ Remove a service
| cinder-volume | devstack@lvmdriver-1 | nova | enabled | up | 2015-10-13T15:21:52.000000 | - |
+------------------+----------------------+------+---------+-------+----------------------------+-----------------+
-#. Disable the service::
+#. Disable the service.
+
+ .. code-block:: console
$ cinder service-disable
-#. Remove the service from the database::
+#. Remove the service from the database.
+
+ .. code-block:: console
$ cinder-manage service remove
diff --git a/doc/user-guide-admin/source/cli_cinder_scheduling.rst b/doc/user-guide-admin/source/cli_cinder_scheduling.rst
index 6a73eaafe7..c8ddaaf179 100644
--- a/doc/user-guide-admin/source/cli_cinder_scheduling.rst
+++ b/doc/user-guide-admin/source/cli_cinder_scheduling.rst
@@ -17,36 +17,36 @@ Example Usages
#. Create new volume on the same back end as Volume_A:
- .. code::
+ .. code-block:: console
$ cinder create --hint same_host=Volume_A-UUID SIZE
#. Create new volume on a different back end than Volume_A:
- .. code::
+ .. code-block:: console
$ cinder create --hint different_host=Volume_A-UUID SIZE
#. Create new volume on the same back end as Volume_A and Volume_B:
- .. code::
+ .. code-block:: console
$ cinder create --hint same_host=Volume_A-UUID --hint same_host=Volume_B-UUID SIZE
Or:
- .. code::
+ .. code-block:: console
$ cinder create --hint same_host="[Volume_A-UUID, Volume_B-UUID]" SIZE
#. Create new volume on a different back end than both Volume_A and Volume_B:
- .. code::
+ .. code-block:: console
$ cinder create --hint different_host=Volume_A-UUID --hint different_host=Volume_B-UUID SIZE
Or:
- .. code::
+ .. code-block:: console
$ cinder create --hint different_host="[Volume_A-UUID, Volume_B-UUID]" SIZE
diff --git a/doc/user-guide-admin/source/cli_keystone_manage_services.rst b/doc/user-guide-admin/source/cli_keystone_manage_services.rst
index 73f13dbf63..5e8a1c1f13 100644
--- a/doc/user-guide-admin/source/cli_keystone_manage_services.rst
+++ b/doc/user-guide-admin/source/cli_keystone_manage_services.rst
@@ -1,19 +1,20 @@
============================================
Create and manage services and service users
============================================
-The Identity Service enables you to define services, as
+
+The Identity service enables you to define services, as
follows:
-- Service catalog template. The Identity Service acts
+- Service catalog template. The Identity service acts
as a service catalog of endpoints for other OpenStack
- services. The :file:`etc/default_catalog.templates`
+ services. The ``etc/default_catalog.templates``
template file defines the endpoints for services. When
- the Identity Service uses a template file back end,
+ the Identity service uses a template file back end,
any changes that are made to the endpoints are cached.
These changes do not persist when you restart the
service or reboot the machine.
- An SQL back end for the catalog service. When the
- Identity Service is online, you must add the services
+ Identity service is online, you must add the services
to the catalog. When you deploy a system for
production, use the SQL back end.
@@ -21,7 +22,7 @@ The ``auth_token`` middleware supports the
use of either a shared secret or users for each
service.
-To authenticate users against the Identity Service, you must
+To authenticate users against the Identity service, you must
create a service user for each OpenStack service. For example,
create a service user for the Compute, Block Storage, and
Networking services.
@@ -37,7 +38,7 @@ Create a service
#. List the available services:
- .. code::
+ .. code-block:: console
$ openstack service list
+----------------------------------+----------+------------+
@@ -54,9 +55,11 @@ Create a service
| 6feb2e0b98874d88bee221974770e372 | s3 | s3 |
+----------------------------------+----------+------------+
-#. To create a service, run this command::
+#. To create a service, run this command:
- $ openstack service create --name SERVICE_NAME --description SERVICE_DESCRIPTION SERVICE_TYPE
+ .. code-block:: console
+
+ $ openstack service create --name SERVICE_NAME --description SERVICE_DESCRIPTION SERVICE_TYPE
The arguments are:
- ``service_name``: the unique name of the new service.
@@ -68,7 +71,7 @@ Create a service
For example, to create a ``swift`` service of type
``object-store``, run this command:
- .. code::
+ .. code-block:: console
$ openstack service create --name swift --description "object store service" object-store
+-------------+----------------------------------+
@@ -81,13 +84,15 @@ Create a service
| type | object-store |
+-------------+----------------------------------+
-#. To get details for a service, run this command::
+#. To get details for a service, run this command:
+
+ .. code-block:: console
$ openstack service show SERVICE_TYPE|SERVICE_NAME|SERVICE_ID
For example:
- .. code::
+ .. code-block:: console
$ openstack service show object-store
+-------------+----------------------------------+
@@ -105,11 +110,13 @@ Create service users
#. Create a project for the service users.
Typically, this project is named ``service``,
- but choose any name you like::
+ but choose any name you like:
+
+ .. code-block:: console
$ openstack project create service
- .. code::
+ .. code-block:: console
+-------------+----------------------------------+
| Field | Value |
@@ -123,11 +130,13 @@ Create service users
#. Create service users for the relevant services for your
deployment.
-#. Assign the admin role to the user-project pair::
+#. Assign the admin role to the user-project pair.
+
+ .. code-block:: console
$ openstack role add --project service --user SERVICE_USER_NAME admin
- .. code::
+ .. code-block:: console
+-------+----------------------------------+
| Field | Value |
@@ -138,12 +147,15 @@ Create service users
Delete a service
~~~~~~~~~~~~~~~~
-To delete a specified service, specify its ID::
-$ openstack service delete SERVICE_TYPE|SERVICE_NAME|SERVICE_ID
+To delete a specified service, specify its ID.
+
+.. code-block:: console
+
+ $ openstack service delete SERVICE_TYPE|SERVICE_NAME|SERVICE_ID
For example:
-.. code::
+.. code-block:: console
$ openstack service delete object-store
diff --git a/doc/user-guide-admin/source/cli_manage_flavors.rst b/doc/user-guide-admin/source/cli_manage_flavors.rst
index 23f7f5d2f2..8e283847dc 100644
--- a/doc/user-guide-admin/source/cli_manage_flavors.rst
+++ b/doc/user-guide-admin/source/cli_manage_flavors.rst
@@ -5,10 +5,11 @@ Manage flavors
In OpenStack, flavors define the compute, memory, and
storage capacity of nova computing instances. To put it
simply, a flavor is an available hardware configuration for a
-server. It defines the "size" of a virtual server
+server. It defines the ``size`` of a virtual server
that can be launched.
.. note::
+
Flavors can also determine on which compute host a flavor
can be used to launch an instance. For information
about customizing flavors, refer to the `OpenStack Cloud Administrator Guide
@@ -70,17 +71,22 @@ Create a flavor
of memory, the amount of disk space for the root
partition and for the ephemeral partition, the
swap, and the number of virtual CPUs for each
- flavor::
+ flavor:
- $ nova flavor-list
+ .. code-block:: console
+
+ $ nova flavor-list
#. To create a flavor, specify a name, ID, RAM
size, disk size, and the number of VCPUs for the
- flavor, as follows::
+ flavor, as follows:
- $ nova flavor-create FLAVOR_NAME FLAVOR_ID RAM_IN_MB ROOT_DISK_IN_GB NUMBER_OF_VCPUS
+ .. code-block:: console
+
+ $ nova flavor-create FLAVOR_NAME FLAVOR_ID RAM_IN_MB ROOT_DISK_IN_GB NUMBER_OF_VCPUS
.. note::
+
Unique ID (integer or UUID) for the new flavor. If
specifying 'auto', a UUID will be automatically generated.
@@ -91,43 +97,53 @@ Create a flavor
one VCPU. The rxtx-factor indicates the slice of
bandwidth that the instances with this flavor can
use (through the Virtual Interface (vif) creation
- in the hypervisor)::
+ in the hypervisor):
- $ nova flavor-create --is-public true m1.extra_tiny auto 256 0 1 --rxtx-factor .1
+ .. code-block:: console
+
+ $ nova flavor-create --is-public true m1.extra_tiny auto 256 0 1 --rxtx-factor .1
#. If an individual user or group of users needs a custom
flavor that you do not want other tenants to have access to,
you can change the flavor's access to make it a private flavor.
See `Private Flavors in the OpenStack Operations Guide `_.
- For a list of optional parameters, run this command::
+ For a list of optional parameters, run this command:
- $ nova help flavor-create
+ .. code-block:: console
+
+ $ nova help flavor-create
#. After you create a flavor, assign it to a
project by specifying the flavor name or ID and
- the tenant ID::
+ the tenant ID:
- $ nova flavor-access-add FLAVOR TENANT_ID
+ .. code-block:: console
+
+ $ nova flavor-access-add FLAVOR TENANT_ID
#. In addition, you can set or unset ``extra_spec`` for the existing flavor.
The ``extra_spec`` metadata keys can influence the instance directly when
it is launched. If a flavor sets the
``extra_spec key/value quota:vif_outbound_peak=65536``, the instance's
out bound peak bandwidth I/O should be LTE 512 Mbps. There are several
- aspects that can work for an instance including **CPU limits**,
- **Disk tuning**, **Bandwidth I/O**, **Watchdog behavior**, and
- **Random-number generator**.
+ aspects that can work for an instance including ``CPU limits``,
+ ``Disk tuning``, ``Bandwidth I/O``, ``Watchdog behavior``, and
+ ``Random-number generator``.
For information about supporting metadata keys, see the
`OpenStack Cloud Administrator Guide
`__.
- For a list of optional parameters, run this command::
+ For a list of optional parameters, run this command:
- $ nova help flavor-key
+ .. code-block:: console
+
+ $ nova help flavor-key
Delete a flavor
~~~~~~~~~~~~~~~
-Delete a specified flavor, as follows::
+Delete a specified flavor, as follows:
-$ nova flavor-delete FLAVOR_ID
+.. code-block:: console
+
+ $ nova flavor-delete FLAVOR_ID
diff --git a/doc/user-guide-admin/source/cli_manage_shares.rst b/doc/user-guide-admin/source/cli_manage_shares.rst
index c299308491..c69bd1b3b2 100644
--- a/doc/user-guide-admin/source/cli_manage_shares.rst
+++ b/doc/user-guide-admin/source/cli_manage_shares.rst
@@ -24,11 +24,13 @@ Possible use cases for data migration include:
- Free up space in a thinly-provisioned back end.
Migrate a share with the :command:`manila migrate` command, as shown in the
-following example::
+following example:
- $ manila migrate shareID destinationHost --force-host-copy True|False
+.. code-block:: console
-In this example, ``--force-host-copy True`` forces the generic
+ $ manila migrate shareID destinationHost --force-host-copy True|False
+
+In this example, :option:`--force-host-copy True` forces the generic
host-based migration mechanism and bypasses any driver optimizations.
``destinationHost`` is in this format ``host#pool`` which includes
destination host and pool.
diff --git a/doc/user-guide-admin/source/cli_nova_evacuate.rst b/doc/user-guide-admin/source/cli_nova_evacuate.rst
index b91e5f7385..0131bc3c89 100644
--- a/doc/user-guide-admin/source/cli_nova_evacuate.rst
+++ b/doc/user-guide-admin/source/cli_nova_evacuate.rst
@@ -12,34 +12,42 @@ To preserve user data on server disk, you must configure shared
storage on the target host. Also, you must validate that the current
VM host is down; otherwise, the evacuation fails with an error.
-#. To list hosts and find a different host for the evacuated instance, run::
+#. To list hosts and find a different host for the evacuated instance, run:
- $ nova host-list
+ .. code-block:: console
+
+ $ nova host-list
#. Evacuate the instance. You can pass the instance password to the
command by using the :option:`--password PWD` option. If you do not
specify a password, one is generated and printed after the command
finishes successfully. The following command evacuates a server
without shared storage from a host that is down to the specified
- HOST_B::
+ HOST_B.
- $ nova evacuate EVACUATED_SERVER_NAME HOST_B
+ .. code-block:: console
+
+ $ nova evacuate EVACUATED_SERVER_NAME HOST_B
The instance is rebuilt from the original image or volume, but preserves
its configuration including its ID, name, uid, IP address, and so on.
- The command returns a password::
+ The command returns a password.
- +-----------+--------------+
- | Property | Value |
- +-----------+--------------+
- | adminPass | kRAJpErnT4xZ |
- +-----------+--------------+
+ .. code-block:: console
+
+ +-----------+--------------+
+ | Property | Value |
+ +-----------+--------------+
+ | adminPass | kRAJpErnT4xZ |
+ +-----------+--------------+
#. To preserve the user disk data on the evacuated server, deploy
OpenStack Compute with a shared file system. To configure your
system, see `Configure migrations
`_
in OpenStack Cloud Administrator Guide. In the following example,
- the password remains unchanged::
+ the password remains unchanged.
- $ nova evacuate EVACUATED_SERVER_NAME HOST_B --on-shared-storage
+ .. code-block:: console
+
+ $ nova evacuate EVACUATED_SERVER_NAME HOST_B --on-shared-storage
diff --git a/doc/user-guide-admin/source/cli_nova_manage_services.rst b/doc/user-guide-admin/source/cli_nova_manage_services.rst
index 09cadc2269..b67b9e3b2a 100644
--- a/doc/user-guide-admin/source/cli_nova_manage_services.rst
+++ b/doc/user-guide-admin/source/cli_nova_manage_services.rst
@@ -7,7 +7,7 @@ examples disable and enable the ``nova-compute`` service.
#. List the Compute services:
- .. code::
+ .. code-block:: console
$ nova service-list
+------------------+----------+----------+---------+-------+----------------------------+-----------------+
@@ -23,7 +23,7 @@ examples disable and enable the ``nova-compute`` service.
#. Disable a nova service:
- .. code::
+ .. code-block:: console
$ nova service-disable localhost.localdomain nova-compute --reason 'trial log'
+----------+--------------+----------+-------------------+
@@ -34,7 +34,7 @@ examples disable and enable the ``nova-compute`` service.
#. Check the service list:
- .. code::
+ .. code-block:: console
$ nova service-list
+------------------+----------+----------+---------+-------+----------------------------+------------------+
@@ -50,7 +50,7 @@ examples disable and enable the ``nova-compute`` service.
#. Enable the service:
- .. code::
+ .. code-block:: console
$ nova service-enable localhost.localdomain nova-compute
+----------+--------------+---------+
@@ -61,7 +61,7 @@ examples disable and enable the ``nova-compute`` service.
#. Check the service list:
- .. code::
+ .. code-block:: console
$ nova service-list
+------------------+----------+----------+---------+-------+----------------------------+-----------------+
diff --git a/doc/user-guide-admin/source/cli_nova_migrate.rst b/doc/user-guide-admin/source/cli_nova_migrate.rst
index 01a8d4f2c3..6a0019889b 100644
--- a/doc/user-guide-admin/source/cli_nova_migrate.rst
+++ b/doc/user-guide-admin/source/cli_nova_migrate.rst
@@ -3,62 +3,69 @@ Migrate single instance to another compute host
===============================================
When you want to move an instance from one compute host to another,
-you can use the ``nova migrate`` command. The scheduler chooses the
+you can use the :command:`nova migrate` command. The scheduler chooses the
destination compute host based on its settings. This process does
not assume that the instance has shared storage available on the
target host.
-#. To list the VMs you want to migrate, run::
+#. To list the VMs you want to migrate, run:
- $ nova list
+ .. code-block:: console
+
+ $ nova list
#. After selecting a VM from the list, run this command where :guilabel:`VM_ID`
- is set to the ID in the list returned in the previous step::
+ is set to the ID in the list returned in the previous step:
- $ nova show VM_ID
+ .. code-block:: console
-#. Now, use the ``nova migrate`` command::
+ $ nova show VM_ID
- $ nova migrate VM_ID
+#. Now, use the :command:`nova migrate` command.
+
+ .. code-block:: console
+
+ $ nova migrate VM_ID
#. To migrate of an instance and watch the status, use this example script:
.. code-block:: bash
- #!/bin/bash
+ #!/bin/bash
- # Provide usage
- usage() {
- echo "Usage: $0 VM_ID"
- exit 1
- }
+ # Provide usage
+ usage() {
+ echo "Usage: $0 VM_ID"
+ exit 1
+ }
- [[ $# -eq 0 ]] && usage
+ [[ $# -eq 0 ]] && usage
- # Migrate the VM to an alternate hypervisor
- echo -n "Migrating instance to alternate host"
- VM_ID=$1
- nova migrate $VM_ID
- VM_OUTPUT=`nova show $VM_ID`
- VM_STATUS=`echo "$VM_OUTPUT" | grep status | awk '{print $4}'`
- while [[ "$VM_STATUS" != "VERIFY_RESIZE" ]]; do
- echo -n "."
- sleep 2
- VM_OUTPUT=`nova show $VM_ID`
- VM_STATUS=`echo "$VM_OUTPUT" | grep status | awk '{print $4}'`
- done
- nova resize-confirm $VM_ID
- echo " instance migrated and resized."
- echo;
+ # Migrate the VM to an alternate hypervisor
+ echo -n "Migrating instance to alternate host"
+ VM_ID=$1
+ nova migrate $VM_ID
+ VM_OUTPUT=`nova show $VM_ID`
+ VM_STATUS=`echo "$VM_OUTPUT" | grep status | awk '{print $4}'`
+ while [[ "$VM_STATUS" != "VERIFY_RESIZE" ]]; do
+ echo -n "."
+ sleep 2
+ VM_OUTPUT=`nova show $VM_ID`
+ VM_STATUS=`echo "$VM_OUTPUT" | grep status | awk '{print $4}'`
+ done
+ nova resize-confirm $VM_ID
+ echo " instance migrated and resized."
+ echo;
- # Show the details for the VM
- echo "Updated instance details:"
- nova show $VM_ID
+ # Show the details for the VM
+ echo "Updated instance details:"
+ nova show $VM_ID
- # Pause to allow users to examine VM details
- read -p "Pausing, press to exit."
+ # Pause to allow users to examine VM details
+ read -p "Pausing, press to exit."
.. note::
+
If you see this error, it means you are either
trying the command with the wrong credentials,
such as a non-admin user, or the ``policy.json``
diff --git a/doc/user-guide-admin/source/cli_nova_numa_libvirt.rst b/doc/user-guide-admin/source/cli_nova_numa_libvirt.rst
index e102221e9a..effc5c23d0 100644
--- a/doc/user-guide-admin/source/cli_nova_numa_libvirt.rst
+++ b/doc/user-guide-admin/source/cli_nova_numa_libvirt.rst
@@ -19,7 +19,7 @@ on the instance to the corresponding NUMA cells on the host. It will also
expose the NUMA topology of the instance to the guest OS.
If you want Compute to pin a particular vCPU as part of this process,
-set the ``vcpu_pin_set`` parameter in the :file:`nova.conf` configuration
+set the ``vcpu_pin_set`` parameter in the ``nova.conf`` configuration
file. For more information about the ``vcpu_pin_set`` parameter, see the
Configuration Reference Guide.
diff --git a/doc/user-guide-admin/source/cli_nova_specify_host.rst b/doc/user-guide-admin/source/cli_nova_specify_host.rst
index bccfc07140..4899d8734e 100644
--- a/doc/user-guide-admin/source/cli_nova_specify_host.rst
+++ b/doc/user-guide-admin/source/cli_nova_specify_host.rst
@@ -7,26 +7,30 @@ host instances are launched on and which roles can boot instances
on this host.
#. To select the host where instances are launched, use
- the ``--availability_zone ZONE:HOST`` parameter on the
+ the :option:`--availability_zone ZONE:HOST` parameter on the
:command:`nova boot` command.
- For example::
+ For example:
- $ nova boot --image --flavor m1.tiny --key_name test --availability-zone nova:server2
+ .. code-block:: console
+
+ $ nova boot --image --flavor m1.tiny --key_name test --availability-zone nova:server2
#. To specify which roles can launch an instance on a
- specified host, enable the :code:`create:forced_host` option in
- the :file:`policy.json` file. By default, this option is
+ specified host, enable the ``create:forced_host`` option in
+ the ``policy.json`` file. By default, this option is
enabled for only the admin role.
#. To view the list of valid compute hosts, use the
- :command:`nova hypervisor-list` command, as follows::
+ :command:`nova hypervisor-list` command.
- $ nova hypervisor-list
- +----+---------------------+
- | ID | Hypervisor hostname |
- +----+---------------------+
- | 1 | server2 |
- | 2 | server3 |
- | 3 | server4 |
- +----+---------------------+
+ .. code-block:: console
+
+ $ nova hypervisor-list
+ +----+---------------------+
+ | ID | Hypervisor hostname |
+ +----+---------------------+
+ | 1 | server2 |
+ | 2 | server3 |
+ | 3 | server4 |
+ +----+---------------------+
diff --git a/doc/user-guide-admin/source/cli_set_compute_quotas.rst b/doc/user-guide-admin/source/cli_set_compute_quotas.rst
index d973f85d0b..973173c6f9 100644
--- a/doc/user-guide-admin/source/cli_set_compute_quotas.rst
+++ b/doc/user-guide-admin/source/cli_set_compute_quotas.rst
@@ -44,204 +44,256 @@ tenant user, as well as update the quota defaults for a new tenant.
View and update Compute quotas for a tenant (project)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
To view and update default quota values
---------------------------------------
-#. List all default quotas for all tenants, as follows::
+#. List all default quotas for all tenants:
- $ nova quota-defaults
+ .. code-block:: console
- For example::
+ $ nova quota-defaults
- $ nova quota-defaults
- +-----------------------------+-------+
- | Quota | Limit |
- +-----------------------------+-------+
- | instances | 10 |
- | cores | 20 |
- | ram | 51200 |
- | floating_ips | 10 |
- | fixed_ips | -1 |
- | metadata_items | 128 |
- | injected_files | 5 |
- | injected_file_content_bytes | 10240 |
- | injected_file_path_bytes | 255 |
- | key_pairs | 100 |
- | security_groups | 10 |
- | security_group_rules | 20 |
- +-----------------------------+-------+
+ For example:
-#. Update a default value for a new tenant, as follows::
+ .. code-block:: console
- $ nova quota-class-update --KEY VALUE default
+ $ nova quota-defaults
+ +-----------------------------+-------+
+ | Quota | Limit |
+ +-----------------------------+-------+
+ | instances | 10 |
+ | cores | 20 |
+ | ram | 51200 |
+ | floating_ips | 10 |
+ | fixed_ips | -1 |
+ | metadata_items | 128 |
+ | injected_files | 5 |
+ | injected_file_content_bytes | 10240 |
+ | injected_file_path_bytes | 255 |
+ | key_pairs | 100 |
+ | security_groups | 10 |
+ | security_group_rules | 20 |
+ +-----------------------------+-------+
- For example::
+#. Update a default value for a new tenant.
- $ nova quota-class-update --instances 15 default
+ .. code-block:: console
+
+ $ nova quota-class-update --KEY VALUE default
+
+ For example:
+
+ .. code-block:: console
+
+ $ nova quota-class-update --instances 15 default
To view quota values for an existing tenant (project)
-----------------------------------------------------
-#. Place the tenant ID in a usable variable, as follows::
+#. Place the tenant ID in a usable variable.
- $ tenant=$(openstack project show -f value -c id TENANT_NAME)
+ .. code-block:: console
-#. List the currently set quota values for a tenant, as follows::
+ $ tenant=$(openstack project show -f value -c id TENANT_NAME)
- $ nova quota-show --tenant $tenant
+#. List the currently set quota values for a tenant.
- For example::
+ .. code-block:: console
- $ nova quota-show --tenant $tenant
- +-----------------------------+-------+
- | Quota | Limit |
- +-----------------------------+-------+
- | instances | 10 |
- | cores | 20 |
- | ram | 51200 |
- | floating_ips | 10 |
- | fixed_ips | -1 |
- | metadata_items | 128 |
- | injected_files | 5 |
- | injected_file_content_bytes | 10240 |
- | injected_file_path_bytes | 255 |
- | key_pairs | 100 |
- | security_groups | 10 |
- | security_group_rules | 20 |
- +-----------------------------+-------+
+ $ nova quota-show --tenant $tenant
+
+ For example:
+
+ .. code-block:: console
+
+ $ nova quota-show --tenant $tenant
+ +-----------------------------+-------+
+ | Quota | Limit |
+ +-----------------------------+-------+
+ | instances | 10 |
+ | cores | 20 |
+ | ram | 51200 |
+ | floating_ips | 10 |
+ | fixed_ips | -1 |
+ | metadata_items | 128 |
+ | injected_files | 5 |
+ | injected_file_content_bytes | 10240 |
+ | injected_file_path_bytes | 255 |
+ | key_pairs | 100 |
+ | security_groups | 10 |
+ | security_group_rules | 20 |
+ +-----------------------------+-------+
To update quota values for an existing tenant (project)
-------------------------------------------------------
-#. Obtain the tenant ID, as follows::
- $ tenant=$(openstack project show -f value -c id TENANT_NAME)
+#. Obtain the tenant ID.
-#. Update a particular quota value, as follows::
+ .. code-block:: console
- $ nova quota-update --QUOTA_NAME QUOTA_VALUE TENANT_ID
+ $ tenant=$(openstack project show -f value -c id TENANT_NAME)
- For example::
+#. Update a particular quota value.
- $ nova quota-update --floating-ips 20 $tenant
- $ nova quota-show --tenant $tenant
- +-----------------------------+-------+
- | Quota | Limit |
- +-----------------------------+-------+
- | instances | 10 |
- | cores | 20 |
- | ram | 51200 |
- | floating_ips | 20 |
- | fixed_ips | -1 |
- | metadata_items | 128 |
- | injected_files | 5 |
- | injected_file_content_bytes | 10240 |
- | injected_file_path_bytes | 255 |
- | key_pairs | 100 |
- | security_groups | 10 |
- | security_group_rules | 20 |
- +-----------------------------+-------+
+ .. code-block:: console
- .. note:: To view a list of options for the :command:`quota-update` command, run::
+ $ nova quota-update --QUOTA_NAME QUOTA_VALUE TENANT_ID
- $ nova help quota-update
+ For example:
+
+ .. code-block:: console
+
+ $ nova quota-update --floating-ips 20 $tenant
+ $ nova quota-show --tenant $tenant
+ +-----------------------------+-------+
+ | Quota | Limit |
+ +-----------------------------+-------+
+ | instances | 10 |
+ | cores | 20 |
+ | ram | 51200 |
+ | floating_ips | 20 |
+ | fixed_ips | -1 |
+ | metadata_items | 128 |
+ | injected_files | 5 |
+ | injected_file_content_bytes | 10240 |
+ | injected_file_path_bytes | 255 |
+ | key_pairs | 100 |
+ | security_groups | 10 |
+ | security_group_rules | 20 |
+ +-----------------------------+-------+
+
+ .. note::
+
+ To view a list of options for the :command:`quota-update` command, run:
+
+ .. code-block:: console
+
+ $ nova help quota-update
View and update Compute quotas for a tenant user
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
To view quota values for a tenant user
--------------------------------------
-#. Place the user ID in a usable variable, as follows::
- $ tenantUser=$(openstack user show -f value -c id USER_NAME)
+#. Place the user ID in a usable variable.
-#. Place the user's tenant ID in a usable variable, as follows::
+ .. code-block:: console
- $ tenant=$(openstack project show -f value -c id TENANT_NAME)
+ $ tenantUser=$(openstack user show -f value -c id USER_NAME)
-#. List the currently set quota values for a tenant user, as follows::
+#. Place the user's tenant ID in a usable variable, as follows:
- $ nova quota-show --user $tenantUser --tenant $tenant
+ .. code-block:: console
- For example::
+ $ tenant=$(openstack project show -f value -c id TENANT_NAME)
- $ nova quota-show --user $tenantUser --tenant $tenant
- +-----------------------------+-------+
- | Quota | Limit |
- +-----------------------------+-------+
- | instances | 10 |
- | cores | 20 |
- | ram | 51200 |
- | floating_ips | 20 |
- | fixed_ips | -1 |
- | metadata_items | 128 |
- | injected_files | 5 |
- | injected_file_content_bytes | 10240 |
- | injected_file_path_bytes | 255 |
- | key_pairs | 100 |
- | security_groups | 10 |
- | security_group_rules | 20 |
- +-----------------------------+-------+
+#. List the currently set quota values for a tenant user.
+
+ .. code-block:: console
+
+ $ nova quota-show --user $tenantUser --tenant $tenant
+
+ For example:
+
+ .. code-block:: console
+
+ $ nova quota-show --user $tenantUser --tenant $tenant
+ +-----------------------------+-------+
+ | Quota | Limit |
+ +-----------------------------+-------+
+ | instances | 10 |
+ | cores | 20 |
+ | ram | 51200 |
+ | floating_ips | 20 |
+ | fixed_ips | -1 |
+ | metadata_items | 128 |
+ | injected_files | 5 |
+ | injected_file_content_bytes | 10240 |
+ | injected_file_path_bytes | 255 |
+ | key_pairs | 100 |
+ | security_groups | 10 |
+ | security_group_rules | 20 |
+ +-----------------------------+-------+
To update quota values for a tenant user
----------------------------------------
-#. Place the user ID in a usable variable, as follows::
- $ tenantUser=$(openstack user show -f value -c id USER_NAME)
+#. Place the user ID in a usable variable.
-#. Place the user's tenant ID in a usable variable, as follows::
+ .. code-block:: console
- $ tenant=$(openstack project show -f value -c id TENANT_NAME)
+ $ tenantUser=$(openstack user show -f value -c id USER_NAME)
-#. Update a particular quota value, as follows::
+#. Place the user's tenant ID in a usable variable, as follows:
- $ nova quota-update --user $tenantUser --QUOTA_NAME QUOTA_VALUE $tenant
+ .. code-block:: console
- For example::
+ $ tenant=$(openstack project show -f value -c id TENANT_NAME)
- $ nova quota-update --user $tenantUser --floating-ips 12 $tenant
- $ nova quota-show --user $tenantUser --tenant $tenant
- +-----------------------------+-------+
- | Quota | Limit |
- +-----------------------------+-------+
- | instances | 10 |
- | cores | 20 |
- | ram | 51200 |
- | floating_ips | 12 |
- | fixed_ips | -1 |
- | metadata_items | 128 |
- | injected_files | 5 |
- | injected_file_content_bytes | 10240 |
- | injected_file_path_bytes | 255 |
- | key_pairs | 100 |
- | security_groups | 10 |
- | security_group_rules | 20 |
- +-----------------------------+-------+
+#. Update a particular quota value, as follows:
- .. note:: To view a list of options for the :command:`quota-update` command, run::
+ .. code-block:: console
- $ nova help quota-update
+ $ nova quota-update --user $tenantUser --QUOTA_NAME QUOTA_VALUE $tenant
+
+ For example:
+
+ .. code-block:: console
+
+ $ nova quota-update --user $tenantUser --floating-ips 12 $tenant
+ $ nova quota-show --user $tenantUser --tenant $tenant
+ +-----------------------------+-------+
+ | Quota | Limit |
+ +-----------------------------+-------+
+ | instances | 10 |
+ | cores | 20 |
+ | ram | 51200 |
+ | floating_ips | 12 |
+ | fixed_ips | -1 |
+ | metadata_items | 128 |
+ | injected_files | 5 |
+ | injected_file_content_bytes | 10240 |
+ | injected_file_path_bytes | 255 |
+ | key_pairs | 100 |
+ | security_groups | 10 |
+ | security_group_rules | 20 |
+ +-----------------------------+-------+
+
+ .. note::
+
+ To view a list of options for the :command:`quota-update` command, run:
+
+ .. code-block:: console
+
+ $ nova help quota-update
To display the current quota usage for a tenant user
----------------------------------------------------
-Use :command:`nova absolute-limits` to get a list of the
-current quota values and the current quota usage::
- $ nova absolute-limits --tenant TENANT_NAME
- +-------------------------+-------+
- | Name | Value |
- +-------------------------+-------+
- | maxServerMeta | 128 |
- | maxPersonality | 5 |
- | maxImageMeta | 128 |
- | maxPersonalitySize | 10240 |
- | maxTotalRAMSize | 51200 |
- | maxSecurityGroupRules | 20 |
- | maxTotalKeypairs | 100 |
- | totalRAMUsed | 0 |
- | maxSecurityGroups | 10 |
- | totalFloatingIpsUsed | 0 |
- | totalInstancesUsed | 0 |
- | totalSecurityGroupsUsed | 0 |
- | maxTotalFloatingIps | 10 |
- | maxTotalInstances | 10 |
- | totalCoresUsed | 0 |
- | maxTotalCores | 20 |
- +-------------------------+-------+
+Use :command:`nova absolute-limits` to get a list of the
+current quota values and the current quota usage:
+
+.. code-block:: console
+
+ $ nova absolute-limits --tenant TENANT_NAME
+ +-------------------------+-------+
+ | Name | Value |
+ +-------------------------+-------+
+ | maxServerMeta | 128 |
+ | maxPersonality | 5 |
+ | maxImageMeta | 128 |
+ | maxPersonalitySize | 10240 |
+ | maxTotalRAMSize | 51200 |
+ | maxSecurityGroupRules | 20 |
+ | maxTotalKeypairs | 100 |
+ | totalRAMUsed | 0 |
+ | maxSecurityGroups | 10 |
+ | totalFloatingIpsUsed | 0 |
+ | totalInstancesUsed | 0 |
+ | totalSecurityGroupsUsed | 0 |
+ | maxTotalFloatingIps | 10 |
+ | maxTotalInstances | 10 |
+ | totalCoresUsed | 0 |
+ | maxTotalCores | 20 |
+ +-------------------------+-------+
diff --git a/doc/user-guide-admin/source/cli_set_quotas.rst b/doc/user-guide-admin/source/cli_set_quotas.rst
index 1df5219324..5e9bb5e4a7 100644
--- a/doc/user-guide-admin/source/cli_set_quotas.rst
+++ b/doc/user-guide-admin/source/cli_set_quotas.rst
@@ -18,27 +18,32 @@ tenant requires more than ten volumes or 1 TB on a compute
node.
.. note::
- To view all tenants (projects), run::
- $ openstack project list
- +----------------------------------+----------+
- | ID | Name |
- +----------------------------------+----------+
- | e66d97ac1b704897853412fc8450f7b9 | admin |
- | bf4a37b885fe46bd86e999e50adad1d3 | services |
- | 21bd1c7c95234fd28f589b60903606fa | tenant01 |
- | f599c5cd1cba4125ae3d7caed08e288c | tenant02 |
- +----------------------------------+----------+
+ To view all tenants (projects), run:
- To display all current users for a tenant, run::
+ .. code-block:: console
- $ openstack user list --project PROJECT_NAME
- +----------------------------------+--------+
- | ID | Name |
- +----------------------------------+--------+
- | ea30aa434ab24a139b0e85125ec8a217 | demo00 |
- | 4f8113c1d838467cad0c2f337b3dfded | demo01 |
- +----------------------------------+--------+
+ $ openstack project list
+ +----------------------------------+----------+
+ | ID | Name |
+ +----------------------------------+----------+
+ | e66d97ac1b704897853412fc8450f7b9 | admin |
+ | bf4a37b885fe46bd86e999e50adad1d3 | services |
+ | 21bd1c7c95234fd28f589b60903606fa | tenant01 |
+ | f599c5cd1cba4125ae3d7caed08e288c | tenant02 |
+ +----------------------------------+----------+
+
+ To display all current users for a tenant, run:
+
+ .. code-block:: console
+
+ $ openstack user list --project PROJECT_NAME
+ +----------------------------------+--------+
+ | ID | Name |
+ +----------------------------------+--------+
+ | ea30aa434ab24a139b0e85125ec8a217 | demo00 |
+ | 4f8113c1d838467cad0c2f337b3dfded | demo01 |
+ +----------------------------------+--------+
.. toctree::
diff --git a/doc/user-guide-admin/source/dashboard.rst b/doc/user-guide-admin/source/dashboard.rst
index 92e19a92c5..ac41ee1458 100644
--- a/doc/user-guide-admin/source/dashboard.rst
+++ b/doc/user-guide-admin/source/dashboard.rst
@@ -4,7 +4,7 @@ OpenStack dashboard
As a cloud administrative user, the OpenStack dashboard lets you
create and manage projects, users, images, and flavors. You can also
-set quotas and create and manage services. For information about using
+set quotas, and create and manage services. For information about using
the dashboard to perform end user tasks, see the `OpenStack End User
Guide `__.
diff --git a/doc/user-guide-admin/source/dashboard_admin_manage_roles.rst b/doc/user-guide-admin/source/dashboard_admin_manage_roles.rst
index 1aeeb47d8c..5d809d63e1 100644
--- a/doc/user-guide-admin/source/dashboard_admin_manage_roles.rst
+++ b/doc/user-guide-admin/source/dashboard_admin_manage_roles.rst
@@ -6,15 +6,17 @@ A role is a personality that a user assumes to perform a specific set
of operations. A role includes a set of rights and privileges. A user
assumes that role inherits those rights and privileges.
-.. note:: OpenStack Identity service defines a user's role on a
- project, but it is completely up to the individual service
- to define what that role means. This is referred to as the
- service's policy. To get details about what the privileges
- for each role are, refer to the :file:`policy.json` file
- available for each service in the
- :file:`/etc/SERVICE/policy.json` file. For example, the
- policy defined for OpenStack Identity service is defined
- in the :file:`/etc/keystone/policy.json` file.
+.. note::
+
+ OpenStack Identity service defines a user's role on a
+ project, but it is completely up to the individual service
+ to define what that role means. This is referred to as the
+ service's policy. To get details about what the privileges
+ for each role are, refer to the ``policy.json`` file
+ available for each service in the
+ ``/etc/SERVICE/policy.json`` file. For example, the
+ policy defined for OpenStack Identity service is defined
+ in the ``/etc/keystone/policy.json`` file.
Create a role
~~~~~~~~~~~~~
@@ -38,8 +40,10 @@ Edit a role
In the :guilabel:`Update Role` window, enter a new name for the role.
#. Click the :guilabel:`Update Role` button to confirm your changes.
-.. note:: Using the dashboard, you can edit only the name assigned to
- a role.
+.. note::
+
+ Using the dashboard, you can edit only the name assigned to
+ a role.
Delete a role
~~~~~~~~~~~~~
diff --git a/doc/user-guide-admin/source/dashboard_admin_manage_stacks.rst b/doc/user-guide-admin/source/dashboard_admin_manage_stacks.rst
index 1c02a63947..705c171176 100644
--- a/doc/user-guide-admin/source/dashboard_admin_manage_stacks.rst
+++ b/doc/user-guide-admin/source/dashboard_admin_manage_stacks.rst
@@ -19,12 +19,13 @@ high availability.
For information about:
-* administrative tasks on the command line, see
+* administrative tasks on the command-line, see
:doc:`cli_admin_manage_stacks`.
.. note::
- There are no administration-specific tasks that can be done through
- the Dashboard.
+
+ There are no administration-specific tasks that can be done through
+ the Dashboard.
* the basic creation and deletion of Orchestration stacks, refer to
the `OpenStack End User Guide
diff --git a/doc/user-guide-admin/source/dashboard_manage_flavors.rst b/doc/user-guide-admin/source/dashboard_manage_flavors.rst
index 5965c3cbcb..b8f4ffa204 100644
--- a/doc/user-guide-admin/source/dashboard_manage_flavors.rst
+++ b/doc/user-guide-admin/source/dashboard_manage_flavors.rst
@@ -83,7 +83,7 @@ Update flavors
#. Click :guilabel:`Save`.
Update Metadata
-~~~~~~~~~~~~~~~~
+~~~~~~~~~~~~~~~
#. Log in to the dashboard.
diff --git a/doc/user-guide-admin/source/dashboard_manage_host_aggregates.rst b/doc/user-guide-admin/source/dashboard_manage_host_aggregates.rst
index 9968e4ff11..c9c03efcb6 100644
--- a/doc/user-guide-admin/source/dashboard_manage_host_aggregates.rst
+++ b/doc/user-guide-admin/source/dashboard_manage_host_aggregates.rst
@@ -18,8 +18,8 @@ To create a host aggregate
#. Log in to the dashboard.
- Choose the admin project from the drop-down list at the top of the
- page.
+ Choose the :guilabel:`admin` project from the drop-down list at the top
+ of the page.
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab and click
the :guilabel:`Host Aggregates` category.
@@ -54,8 +54,8 @@ existing aggregate, edit the aggregate.
To manage host aggregates
~~~~~~~~~~~~~~~~~~~~~~~~~
-#. Choose the admin project from the drop-down list at the top of the
- page.
+#. Choose the :guilabel:`admin` project from the drop-down list at the top
+ of the page.
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab and click
the :guilabel:`Host Aggregates` category.
diff --git a/doc/user-guide-admin/source/dashboard_manage_instances.rst b/doc/user-guide-admin/source/dashboard_manage_instances.rst
index 3082a19431..764a64d52b 100644
--- a/doc/user-guide-admin/source/dashboard_manage_instances.rst
+++ b/doc/user-guide-admin/source/dashboard_manage_instances.rst
@@ -13,7 +13,7 @@ user, see the `OpenStack End User Guide