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