openstack
/
openstack-manuals
Code Issues Proposed changes

[user-guide-admin] Fix rst markups whereever required 

Implements: blueprint user-guides-reorganised

Change-Id: I147cd09381789a48f361552055e01469746cb398
This commit is contained in:
venkatamahesh 2015-12-16 00:27:09 +05:30
parent 96d208e736
commit d1808ed9c8
28 changed files with 906 additions and 692 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

161
doc/user-guide-admin/source/analyzing-log-files-with-swift-cli.rst
View File

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

109
doc/user-guide-admin/source/cli_admin_manage_ip_addresses.rst
View File

@ -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 <http://docs.openstack.org/user-guide/>`_.
file. For basic floating-IP procedures, refer to the ``Manage IP
Addresses`` section in the `OpenStack End User Guide <http://docs.openstack.org/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

2
doc/user-guide-admin/source/cli_admin_manage_stacks.rst
View File

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

42
doc/user-guide-admin/source/cli_cinder_quotas.rst
View File

@ -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 <http://docs.openstack.org/liberty/config-reference/content/ch_configuring-openstack-block-storage.html>`_.
#. 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 <host> <binary>
#. Remove the service from the database::
#. Remove the service from the database.
.. code-block:: console
$ cinder-manage service remove <binary> <host>

12
doc/user-guide-admin/source/cli_cinder_scheduling.rst
View File

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

50
doc/user-guide-admin/source/cli_keystone_manage_services.rst
View File

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

52
doc/user-guide-admin/source/cli_manage_flavors.rst
View File

@ -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 <http://docs.openstack.org/openstack-ops/content/private-flavors.html>`_.
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
<http://docs.openstack.org/admin-guide-cloud/compute-flavors.html>`__.
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

8
doc/user-guide-admin/source/cli_manage_shares.rst
View File

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

32
doc/user-guide-admin/source/cli_nova_evacuate.rst
View File

@ -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
<http://docs.openstack.org/admin-guide-cloud/compute-configuring-migrations.html>`_
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

10
doc/user-guide-admin/source/cli_nova_manage_services.rst
View File

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

75
doc/user-guide-admin/source/cli_nova_migrate.rst
View File

@ -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 <enter> to exit."
# Pause to allow users to examine VM details
read -p "Pausing, press <enter> 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``

2
doc/user-guide-admin/source/cli_nova_numa_libvirt.rst
View File

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

32
doc/user-guide-admin/source/cli_nova_specify_host.rst
View File

@ -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 <uuid> --flavor m1.tiny --key_name test --availability-zone nova:server2
.. code-block:: console
$ nova boot --image <uuid> --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 |
+----+---------------------+

342
doc/user-guide-admin/source/cli_set_compute_quotas.rst
View File

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

41
doc/user-guide-admin/source/cli_set_quotas.rst
View File

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

2
doc/user-guide-admin/source/dashboard.rst
View File

@ -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 <http://docs.openstack.org/user-guide/>`__.

26
doc/user-guide-admin/source/dashboard_admin_manage_roles.rst
View File

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

7
doc/user-guide-admin/source/dashboard_admin_manage_stacks.rst
View File

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

2
doc/user-guide-admin/source/dashboard_manage_flavors.rst
View File

@ -83,7 +83,7 @@ Update flavors
#. Click :guilabel:`Save`.
Update Metadata
~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~
#. Log in to the dashboard.

8
doc/user-guide-admin/source/dashboard_manage_host_aggregates.rst
View File

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

6
doc/user-guide-admin/source/dashboard_manage_instances.rst
View File

@ -13,7 +13,7 @@ user, see the `OpenStack End User Guide <http://docs.openstack.org/user-guide/da
Create instance snapshots
~~~~~~~~~~~~~~~~~~~~~~~~~
#. Log in to the Dashboard and choose the admin project from the
#. Log in to the Dashboard and 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
@ -35,7 +35,7 @@ Create instance snapshots
Control the state of an instance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#. Log in to the Dashboard and choose the admin project from the
#. Log in to the Dashboard and 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
@ -64,7 +64,7 @@ for each project.
You can track costs per month by showing meters like number of VCPUs,
disks, RAM, and uptime of all your instances.
#. Log in to the Dashboard and choose the admin project from the
#. Log in to the Dashboard and choose the :guilabel:`admin` project from the
drop-down list at the top of the page.
#. On the :guilabel:`Admin` tab, click the :guilabel:`Instances` category.

6
doc/user-guide-admin/source/dashboard_manage_services.rst
View File

@ -19,12 +19,12 @@ As an administrative user, you can view information for OpenStack services.
and whether or not the service is enabled.
* :guilabel:`Compute Services`:
Displays information specific to the Compute Service. Both host
Displays information specific to the Compute service. Both host
and zone are listed for each service, as well as its
activation status.
* :guilabel:`Block Storage Services`:
Displays information specific to the Block Storage Service. Both host
Displays information specific to the Block Storage service. Both host
and zone are listed for each service, as well as its
activation status.
@ -33,6 +33,6 @@ As an administrative user, you can view information for OpenStack services.
DHCP agents, and the status of each agent.
* :guilabel:`Orchestration Services`:
Displays information specific to the Orchestration Service. Name,
Displays information specific to the Orchestration service. Name,
engine id, host and topic are listed for each service, as well as its
activation status.

24
doc/user-guide-admin/source/dashboard_manage_shares.rst
View File

@ -36,7 +36,9 @@ Create a share type
#. Click :guilabel:`Create Share Type` button to confirm your changes.
.. note:: A message indicates whether the action succeeded.
.. note::
A message indicates whether the action succeeded.
Update share type
~~~~~~~~~~~~~~~~~
@ -59,7 +61,9 @@ Update share type
#. Click :guilabel:`Update Share Type` button to confirm your changes.
.. note:: A message indicates whether the action succeeded.
.. note::
A message indicates whether the action succeeded.
Delete share types
~~~~~~~~~~~~~~~~~~
@ -80,7 +84,9 @@ When you delete a share type, shares of that type are not deleted.
#. In the :guilabel:`Confirm Delete Share Types` window, click the
:guilabel:`Delete Share Types` button to confirm the action.
.. note:: A message indicates whether the action succeeded.
.. note::
A message indicates whether the action succeeded.
Delete shares
~~~~~~~~~~~~~
@ -98,7 +104,9 @@ Delete shares
#. In the :guilabel:`Confirm Delete Shares` window, click the
:guilabel:`Delete Shares` button to confirm the action.
.. note:: A message indicates whether the action succeeded.
.. note::
A message indicates whether the action succeeded.
Delete share server
~~~~~~~~~~~~~~~~~~~
@ -116,7 +124,9 @@ Delete share server
#. In the :guilabel:`Confirm Delete Share Server` window, click the
:guilabel:`Delete Share Server` button to confirm the action.
.. note:: A message indicates whether the action succeeded.
.. note::
A message indicates whether the action succeeded.
Delete share networks
~~~~~~~~~~~~~~~~~~~~~
@ -134,4 +144,6 @@ Delete share networks
#. In the :guilabel:`Confirm Delete Share Networks` window, click the
:guilabel:`Delete Share Networks` button to confirm the action.
.. note:: A message indicates whether the action succeeded.
.. note::
A message indicates whether the action succeeded.

13
doc/user-guide-admin/source/dashboard_manage_volumes.rst
View File

@ -30,7 +30,9 @@ Create a volume type
#. Click :guilabel:`Create Volume Type` button to confirm your changes.
.. note:: A message indicates whether the action succeeded.
.. note::
A message indicates whether the action succeeded.
Create an encrypted volume type
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -56,6 +58,7 @@ Create an encrypted volume type
#. Click :guilabel:`Create Volume Type Encryption`.
.. note::
Once a volume type is updated by the :guilabel:`Create
Encryption` option, the volume type cannot be deleted.
@ -133,7 +136,9 @@ When you delete a volume type, volumes of that type are not deleted.
#. In the :guilabel:`Confirm Delete Volume Types` window, click the
:guilabel:`Delete Volume Types` button to confirm the action.
.. note:: A message indicates whether the action succeeded.
.. note::
A message indicates whether the action succeeded.
Delete volumes
~~~~~~~~~~~~~~
@ -154,4 +159,6 @@ destroyed.
#. In the :guilabel:`Confirm Delete Volumes` window, click the
:guilabel:`Delete Volumes` button to confirm the action.
.. note:: A message indicates whether the action succeeded.
.. note::
A message indicates whether the action succeeded.

3
doc/user-guide-admin/source/dashboard_set_quotas.rst
View File

@ -20,6 +20,7 @@ Using the Dashboard, you can view default Compute and Block Storage
quotas for new tenants, as well as update quotas for existing tenants.
.. note::
Using the command-line interface, you can manage quotas for the
OpenStack Compute service, the OpenStack Block Storage service, and
the OpenStack Networking service (see :doc:`cli_set_quotas`).
@ -84,6 +85,7 @@ View default project quotas
#. The default quota values are displayed.
.. note::
You can sort the table by clicking on either the
:guilabel:`Quota Name` or :guilabel:`Limit` column headers.
@ -105,6 +107,7 @@ Update project quotas
#. Click the :guilabel:`Update Defaults` button.
.. note::
The dashboard does not show all possible project quotas.
To view and update the quotas for a service, use its
command-line client. See :doc:`cli_set_quotas`.

80
doc/user-guide-admin/source/manage_projects_users_and_roles.rst
View File

@ -44,7 +44,7 @@ List projects
List all projects with their ID, name, and whether they are
enabled or disabled:
.. code:: console
.. code-block:: console
$ openstack project list
+----------------------------------+--------------------+
@ -63,7 +63,7 @@ Create a project
Create a project named ``new-project``:
.. code:: console
.. code-block:: console
$ openstack project create --description 'my new project' new-project
+-------------+----------------------------------+
@ -83,42 +83,42 @@ description, and enabled status of a project.
- To temporarily disable a project:
.. code:: console
.. code-block:: console
$ openstack project set PROJECT_ID --disable
$ openstack project set PROJECT_ID --disable
- To enable a disabled project:
.. code:: console
.. code-block:: console
$ openstack project set PROJECT_ID --enable
$ openstack project set PROJECT_ID --enable
- To update the name of a project:
.. code:: console
.. code-block:: console
$ openstack project set PROJECT_ID --name project-new
$ openstack project set PROJECT_ID --name project-new
- To verify your changes, show information for the updated project:
.. code:: console
.. code-block:: console
$ openstack project show PROJECT_ID
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | my new project |
| enabled | True |
| id | 1a4a0618b306462c9830f876b0bd6af2 |
| name | project-new |
+-------------+----------------------------------+
$ openstack project show PROJECT_ID
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | my new project |
| enabled | True |
| id | 1a4a0618b306462c9830f876b0bd6af2 |
| name | project-new |
+-------------+----------------------------------+
Delete a project
^^^^^^^^^^^^^^^^
Specify the project ID to delete a project:
.. code:: console
.. code-block:: console
$ openstack project delete PROJECT_ID
@ -130,7 +130,7 @@ List users
List all users:
.. code:: console
.. code-block:: console
$ openstack user list
+----------------------------------+----------+
@ -152,7 +152,7 @@ log in to the dashboard without this information.
Create the ``new-user`` user:
.. code:: console
.. code-block:: console
$ openstack user create --project new-project --password PASSWORD new-user
+----------+----------------------------------+
@ -172,9 +172,9 @@ You can update the name, email address, and enabled status for a user.
- To temporarily disable a user account:
.. code:: console
.. code-block:: console
$ openstack user set USER_NAME --disable
$ openstack user set USER_NAME --disable
If you disable a user account, the user cannot log in to the
dashboard. However, data for the user account is maintained, so you
@ -182,23 +182,23 @@ You can update the name, email address, and enabled status for a user.
- To enable a disabled user account:
.. code:: console
.. code-block:: console
$ openstack user set USER_NAME --enable
$ openstack user set USER_NAME --enable
- To change the name and description for a user account:
.. code:: console
.. code-block:: console
$ openstack user set USER_NAME --name user-new --email new-user@example.com
User has been updated.
$ openstack user set USER_NAME --name user-new --email new-user@example.com
User has been updated.
Delete a user
^^^^^^^^^^^^^
Delete a specified user account:
.. code:: console
.. code-block:: console
$ openstack user delete USER_NAME
@ -210,7 +210,7 @@ List available roles
List the available roles:
.. code:: console
.. code-block:: console
$ openstack role list
+----------------------------------+---------------+
@ -231,7 +231,7 @@ projects, define a role and assign that role to a user-project pair.
Create the ``new-role`` role:
.. code:: console
.. code-block:: console
$ openstack role create new-role
+--------+----------------------------------+
@ -250,7 +250,7 @@ IDs.
#. List users and note the user ID you want to assign to the role:
.. code:: console
.. code-block:: console
$ openstack user list
+----------------------------------+----------+---------+----------------------+
@ -266,7 +266,7 @@ IDs.
#. List role IDs and note the role ID you want to assign:
.. code:: console
.. code-block:: console
$ openstack role list
+----------------------------------+---------------+
@ -282,7 +282,7 @@ IDs.
#. List projects and note the project ID you want to assign to the role:
.. code:: console
.. code-block:: console
$ openstack project list
+----------------------------------+--------------------+---------+
@ -301,13 +301,13 @@ IDs.
#. Assign a role to a user-project pair. In this example, assign the
``new-role`` role to the ``demo`` and ``test-project`` pair:
.. code:: console
.. code-block:: console
$ openstack role add --user USER_NAME --project TENANT_ID ROLE_NAME
#. Verify the role assignment:
.. code:: console
.. code-block:: console
$ openstack role list --user USER_NAME --project TENANT_ID
+--------------+----------+---------------------------+--------------+
@ -321,7 +321,7 @@ View role details
View details for a specified role:
.. code:: console
.. code-block:: console
$ openstack role show ROLE_NAME
+----------+----------------------------------+
@ -336,15 +336,15 @@ Remove a role
Remove a role from a user-project pair:
#. Run :command:`openstack role remove`:
#. Run the :command:`openstack role remove` command:
.. code:: console
.. code-block:: console
$ openstack role remove --user USER_NAME --project TENANT_ID ROLE_NAME
#. Verify the role removal:
.. code:: console
.. code-block:: console
$ openstack role list --user USER_NAME --project TENANT_ID

310
doc/user-guide-admin/source/networking_advanced_quotas.rst
View File

@ -5,7 +5,7 @@ A quota limits the number of available resources. A default
quota might be enforced for all tenants. When you try to create
more resources than the quota allows, an error occurs:
.. code:: ini
.. code-block:: ini
$ neutron net-create test_net
Quota exceeded for resources: ['network']
@ -20,61 +20,63 @@ the same quota values, such as the number of resources that a
tenant can create.
The quota value is defined in the OpenStack Networking
:file:`neutron.conf` configuration file. To disable quotas for
``neutron.conf`` configuration file. To disable quotas for
a specific resource, such as network, subnet,
or port, remove a corresponding item from :code:`quota_items`.
or port, remove a corresponding item from ``quota_items``.
This example shows the default quota values:
.. code:: ini
.. code-block:: ini
[quotas]
# resource name(s) that are supported in quota features
quota_items = network,subnet,port
[quotas]
# resource name(s) that are supported in quota features
quota_items = network,subnet,port
# number of networks allowed per tenant, and minus means unlimited
quota_network = 10
# number of networks allowed per tenant, and minus means unlimited
quota_network = 10
# number of subnets allowed per tenant, and minus means unlimited
quota_subnet = 10
# number of subnets allowed per tenant, and minus means unlimited
quota_subnet = 10
# number of ports allowed per tenant, and minus means unlimited
quota_port = 50
# number of ports allowed per tenant, and minus means unlimited
quota_port = 50
# default driver to use for quota checks
quota_driver = neutron.quota.ConfDriver
# default driver to use for quota checks
quota_driver = neutron.quota.ConfDriver
OpenStack Networking also supports quotas for L3 resources:
router and floating IP. Add these lines to the
``quotas`` section in the :file:`neutron.conf` file:
``quotas`` section in the ``neutron.conf`` file:
.. code:: ini
.. code-block:: ini
[quotas]
# number of routers allowed per tenant, and minus means unlimited
quota_router = 10
[quotas]
# number of routers allowed per tenant, and minus means unlimited
quota_router = 10
# number of floating IPs allowed per tenant, and minus means unlimited
quota_floatingip = 50
# number of floating IPs allowed per tenant, and minus means unlimited
quota_floatingip = 50
.. note::
The :code:`quota_items` option does not affect these quotas.
The ``quota_items`` option does not affect these quotas.
OpenStack Networking also supports quotas for security group
resources: number of security groups and the number of rules for
each security group. Add these lines to the
``quotas`` section in the :file:`neutron.conf` file:
``quotas`` section in the ``neutron.conf`` file:
.. code:: ini
.. code-block:: ini
[quotas]
# number of security groups per tenant, and minus means unlimited
quota_security_group = 10
[quotas]
# number of security groups per tenant, and minus means unlimited
quota_security_group = 10
# number of security rules allowed per tenant, and minus means unlimited
quota_security_group_rule = 100
# number of security rules allowed per tenant, and minus means unlimited
quota_security_group_rule = 100
.. note::
The :code:`quota_items` option does not affect these quotas.
The ``quota_items`` option does not affect these quotas.
.. _cfg_quotas_per_tenant:
@ -103,50 +105,58 @@ the default set of quotas are enforced for all tenants, so no
#. Configure Networking to show per-tenant quotas
Set the :code:`quota_driver` option in the :file:`neutron.conf` file::
Set the ``quota_driver`` option in the ``neutron.conf`` file.
quota_driver = neutron.db.quota_db.DbQuotaDriver
.. code-block:: ini
quota_driver = neutron.db.quota_db.DbQuotaDriver
When you set this option, the output for Networking commands shows ``quotas``.
#. List Networking extensions.
To list the Networking extensions, run this command::
To list the Networking extensions, run this command:
$ neutron ext-list -c alias -c name
.. code-block:: console
$ neutron ext-list -c alias -c name
The command shows the ``quotas`` extension, which provides
per-tenant quota management support::
per-tenant quota management support.
+-----------------+--------------------------+
| alias | name |
+-----------------+--------------------------+
| agent_scheduler | Agent Schedulers |
| security-group | security-group |
| binding | Port Binding |
| quotas | Quota management support |
| agent | agent |
| provider | Provider Network |
| router | Neutron L3 Router |
| lbaas | LoadBalancing service |
| extraroute | Neutron Extra Route |
+-----------------+--------------------------+
.. code-block:: console
+-----------------+--------------------------+
| alias | name |
+-----------------+--------------------------+
| agent_scheduler | Agent Schedulers |
| security-group | security-group |
| binding | Port Binding |
| quotas | Quota management support |
| agent | agent |
| provider | Provider Network |
| router | Neutron L3 Router |
| lbaas | LoadBalancing service |
| extraroute | Neutron Extra Route |
+-----------------+--------------------------+
#. Show information for the quotas extension.
To show information for the ``quotas`` extension, run this command::
To show information for the ``quotas`` extension, run this command:
$ neutron ext-show quotas
+-------------+------------------------------------------------------------+
| Field | Value |
+-------------+------------------------------------------------------------+
| alias | quotas |
| description | Expose functions for quotas management per tenant |
| links | |
| name | Quota management support |
| namespace | http://docs.openstack.org/network/ext/quotas-sets/api/v2.0 |
| updated | 2012-07-29T10:00:00-00:00 |
+-------------+------------------------------------------------------------+
.. code-block:: console
$ neutron ext-show quotas
+-------------+------------------------------------------------------------+
| Field | Value |
+-------------+------------------------------------------------------------+
| alias | quotas |
| description | Expose functions for quotas management per tenant |
| links | |
| name | Quota management support |
| namespace | http://docs.openstack.org/network/ext/quotas-sets/api/v2.0 |
| updated | 2012-07-29T10:00:00-00:00 |
+-------------+------------------------------------------------------------+
.. note::
@ -160,40 +170,46 @@ the default set of quotas are enforced for all tenants, so no
The :command:`quota-list` command lists tenants for which the per-tenant
quota is enabled. The command does not list tenants with default
quota support. You must be an administrative user to run this command::
quota support. You must be an administrative user to run this command:
$ neutron quota-list
+------------+---------+------+--------+--------+----------------------------------+
| floatingip | network | port | router | subnet | tenant_id |
+------------+---------+------+--------+--------+----------------------------------+
| 20 | 5 | 20 | 10 | 5 | 6f88036c45344d9999a1f971e4882723 |
| 25 | 10 | 30 | 10 | 10 | bff5c9455ee24231b5bc713c1b96d422 |
+------------+---------+------+--------+--------+----------------------------------+
.. code-block:: console
$ neutron quota-list
+------------+---------+------+--------+--------+----------------------------------+
| floatingip | network | port | router | subnet | tenant_id |
+------------+---------+------+--------+--------+----------------------------------+
| 20 | 5 | 20 | 10 | 5 | 6f88036c45344d9999a1f971e4882723 |
| 25 | 10 | 30 | 10 | 10 | bff5c9455ee24231b5bc713c1b96d422 |
+------------+---------+------+--------+--------+----------------------------------+
#. Show per-tenant quota values.
The :command:`quota-show` command reports the current
set of quota limits for the specified tenant.
Non-administrative users can run this command without the
``--tenant_id`` parameter. If per-tenant quota limits are
:option:`--tenant_id` parameter. If per-tenant quota limits are
not enabled for the tenant, the command shows the default
set of quotas::
set of quotas.
$ neutron quota-show --tenant_id 6f88036c45344d9999a1f971e4882723
+------------+-------+
| Field | Value |
+------------+-------+
| floatingip | 20 |
| network | 5 |
| port | 20 |
| router | 10 |
| subnet | 5 |
+------------+-------+
.. code-block:: console
$ neutron quota-show --tenant_id 6f88036c45344d9999a1f971e4882723
+------------+-------+
| Field | Value |
+------------+-------+
| floatingip | 20 |
| network | 5 |
| port | 20 |
| router | 10 |
| subnet | 5 |
+------------+-------+
The following command shows the command output for a
non-administrative user::
non-administrative user.
$ neutron quota-show
.. code-block:: console
$ neutron quota-show
+------------+-------+
| Field | Value |
+------------+-------+
@ -207,84 +223,96 @@ the default set of quotas are enforced for all tenants, so no
#. Update quota values for a specified tenant.
Use the :command:`quota-update` command to
update a quota for a specified tenant::
update a quota for a specified tenant.
$ neutron quota-update --tenant_id 6f88036c45344d9999a1f971e4882723 --network 5
+------------+-------+
| Field | Value |
+------------+-------+
| floatingip | 50 |
| network | 5 |
| port | 50 |
| router | 10 |
| subnet | 10 |
+------------+-------+
.. code-block:: console
$ neutron quota-update --tenant_id 6f88036c45344d9999a1f971e4882723 --network 5
+------------+-------+
| Field | Value |
+------------+-------+
| floatingip | 50 |
| network | 5 |
| port | 50 |
| router | 10 |
| subnet | 10 |
+------------+-------+
You can update quotas for multiple resources through one
command::
command.
$ neutron quota-update --tenant_id 6f88036c45344d9999a1f971e4882723 --subnet 5 --port 20
+------------+-------+
| Field | Value |
+------------+-------+
| floatingip | 50 |
| network | 5 |
| port | 20 |
| router | 10 |
| subnet | 5 |
+------------+-------+
.. code-block:: console
$ neutron quota-update --tenant_id 6f88036c45344d9999a1f971e4882723 --subnet 5 --port 20
+------------+-------+
| Field | Value |
+------------+-------+
| floatingip | 50 |
| network | 5 |
| port | 20 |
| router | 10 |
| subnet | 5 |
+------------+-------+
To update the limits for an L3 resource such as, router
or floating IP, you must define new values for the quotas
after the ``--`` directive.
This example updates the limit of the number of floating
IPs for the specified tenant::
IPs for the specified tenant.
$ neutron quota-update --tenant_id 6f88036c45344d9999a1f971e4882723 -- --floatingip 20
+------------+-------+
| Field | Value |
+------------+-------+
| floatingip | 20 |
| network | 5 |
| port | 20 |
| router | 10 |
| subnet | 5 |
+------------+-------+
.. code-block:: console
$ neutron quota-update --tenant_id 6f88036c45344d9999a1f971e4882723 -- --floatingip 20
+------------+-------+
| Field | Value |
+------------+-------+
| floatingip | 20 |
| network | 5 |
| port | 20 |
| router | 10 |
| subnet | 5 |
+------------+-------+
You can update the limits of multiple resources by
including L2 resources and L3 resource through one
command::
command:
$ neutron quota-update --tenant_id 6f88036c45344d9999a1f971e4882723 --network 3 --subnet 3 --port 3 -- --floatingip 3 --router 3
+------------+-------+
| Field | Value |
+------------+-------+
| floatingip | 3 |
| network | 3 |
| port | 3 |
| router | 3 |
| subnet | 3 |
+------------+-------+
.. code-block:: console
$ neutron quota-update --tenant_id 6f88036c45344d9999a1f971e4882723 --network 3 --subnet 3 --port 3 -- --floatingip 3 --router 3
+------------+-------+
| Field | Value |
+------------+-------+
| floatingip | 3 |
| network | 3 |
| port | 3 |
| router | 3 |
| subnet | 3 |
+------------+-------+
#. Delete per-tenant quota values.
To clear per-tenant quota limits, use the
:command:`quota-delete` command::
:command:`quota-delete` command.
$ neutron quota-delete --tenant_id 6f88036c45344d9999a1f971e4882723
Deleted quota: 6f88036c45344d9999a1f971e4882723
.. code-block:: console
$ neutron quota-delete --tenant_id 6f88036c45344d9999a1f971e4882723
Deleted quota: 6f88036c45344d9999a1f971e4882723
After you run this command, you can see that quota
values for the tenant are reset to the default values::
values for the tenant are reset to the default values.
$ neutron quota-show --tenant_id 6f88036c45344d9999a1f971e4882723
+------------+-------+
| Field | Value |
+------------+-------+
| floatingip | 50 |
| network | 10 |
| port | 50 |
| router | 10 |
| subnet | 10 |
+------------+-------+
.. code-block:: console
$ neutron quota-show --tenant_id 6f88036c45344d9999a1f971e4882723
+------------+-------+
| Field | Value |
+------------+-------+
| floatingip | 50 |
| network | 10 |
| port | 50 |
| router | 10 |
| subnet | 10 |
+------------+-------+

141
doc/user-guide-admin/source/nova_cli_manage_projects_security.rst
View File

@ -7,13 +7,13 @@ project instances, which define networking access to the instance. Group
rules are project specific; project members can edit the default rules
for their group and add new rule sets.
All projects have a "default" security group which is applied to any
All projects have a ``default`` security group which is applied to any
instance that has no other defined security group. Unless you change the
default, this security group denies all incoming traffic and allows only
outgoing traffic to your instance.
You can use the ``allow_same_net_traffic`` option in the
:file:`/etc/nova/nova.conf` file to globally control whether the rules apply
``/etc/nova/nova.conf`` file to globally control whether the rules apply
to hosts which share a network.
If set to:
@ -35,47 +35,48 @@ section).
List and view current security groups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From the command line you can get a list of security groups for the
project, using the nova command:
From the command-line you can get a list of security groups for the
project, using the :command:`nova` command:
#. Ensure your system variables are set for the user and tenant for
which you are checking security group rules for. For example:
.. code::
.. code-block:: console
export OS_USERNAME=demo00
export OS_TENANT_NAME=tenant01
export OS_USERNAME=demo00
export OS_TENANT_NAME=tenant01
#. Output security groups, as follows:
.. code::
.. code-block:: console
$ nova secgroup-list
+---------+-------------+
| Name | Description |
+---------+-------------+
| default | default |
| open | all ports |
+---------+-------------+
$ nova secgroup-list
+---------+-------------+
| Name | Description |
+---------+-------------+
| default | default |
| open | all ports |
+---------+-------------+
#. View the details of a group, as follows:
.. code::
.. code-block:: console
$ nova secgroup-list-rules groupName
$ nova secgroup-list-rules groupName
For example:
.. code::
.. code-block:: console
$ nova secgroup-list-rules open
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| icmp | -1 | 255 | 0.0.0.0/0 | |
| tcp | 1 | 65535 | 0.0.0.0/0 | |
| udp | 1 | 65535 | 0.0.0.0/0 | |
+-------------+-----------+---------+-----------+--------------+
$ nova secgroup-list-rules open
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| icmp | -1 | 255 | 0.0.0.0/0 | |
| tcp | 1 | 65535 | 0.0.0.0/0 | |
| udp | 1 | 65535 | 0.0.0.0/0 | |
+-------------+-----------+---------+-----------+--------------+
These rules are allow type rules as the default is deny. The first
column is the IP protocol (one of icmp, tcp, or udp). The second and
@ -96,90 +97,92 @@ easier to understand than "bobs\_group" or "secgrp1".
#. Add the new security group, as follows:
.. code::
.. code-block:: console
$ nova secgroup-create Group Name Description
$ nova secgroup-create Group Name Description
For example:
.. code::
.. code-block:: console
$ nova secgroup-create global_http "Allows Web traffic anywhere on the Internet."
+--------------------------------------+-------------+----------------------------------------------+
| Id | Name | Description |
+--------------------------------------+-------------+----------------------------------------------+
| 1578a08c-5139-4f3e-9012-86bd9dd9f23b | global_http | Allows Web traffic anywhere on the Internet. |
+--------------------------------------+-------------+----------------------------------------------+
$ nova secgroup-create global_http "Allows Web traffic anywhere on the Internet."
+--------------------------------------+-------------+----------------------------------------------+
| Id | Name | Description |
+--------------------------------------+-------------+----------------------------------------------+
| 1578a08c-5139-4f3e-9012-86bd9dd9f23b | global_http | Allows Web traffic anywhere on the Internet. |
+--------------------------------------+-------------+----------------------------------------------+
#. Add a new group rule, as follows:
.. code::
.. code-block:: console
$ nova secgroup-add-rule secGroupName ip-protocol from-port to-port CIDR
$ nova secgroup-add-rule secGroupName ip-protocol from-port to-port CIDR
The arguments are positional, and the "from-port" and "to-port"
The arguments are positional, and the ``from-port`` and ``to-port``
arguments specify the local port range connections are allowed to
access, not the source and destination ports of the connection. For
example:
.. code::
.. code-block:: console
$ nova secgroup-add-rule global_http tcp 80 80 0.0.0.0/0
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp | 80 | 80 | 0.0.0.0/0 | |
+-------------+-----------+---------+-----------+--------------+
$ nova secgroup-add-rule global_http tcp 80 80 0.0.0.0/0
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp | 80 | 80 | 0.0.0.0/0 | |
+-------------+-----------+---------+-----------+--------------+
You can create complex rule sets by creating additional rules. For
example, if you want to pass both HTTP and HTTPS traffic, run:
.. code::
.. code-block:: console
$ nova secgroup-add-rule global_http tcp 443 443 0.0.0.0/0
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp | 443 | 443 | 0.0.0.0/0 | |
+-------------+-----------+---------+-----------+--------------+
$ nova secgroup-add-rule global_http tcp 443 443 0.0.0.0/0
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp | 443 | 443 | 0.0.0.0/0 | |
+-------------+-----------+---------+-----------+--------------+
Despite only outputting the newly added rule, this operation is
additive (both rules are created and enforced).
#. View all rules for the new security group, as follows:
.. code::
.. code-block:: console
$ nova secgroup-list-rules global_http
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp | 80 | 80 | 0.0.0.0/0 | |
| tcp | 443 | 443 | 0.0.0.0/0 | |
+-------------+-----------+---------+-----------+--------------+
$ nova secgroup-list-rules global_http
+-------------+-----------+---------+-----------+--------------+
| IP Protocol | From Port | To Port | IP Range | Source Group |
+-------------+-----------+---------+-----------+--------------+
| tcp | 80 | 80 | 0.0.0.0/0 | |
| tcp | 443 | 443 | 0.0.0.0/0 | |
+-------------+-----------+---------+-----------+--------------+
Delete a security group
~~~~~~~~~~~~~~~~~~~~~~~
#. Ensure your system variables are set for the user and tenant for
which you are deleting a security group for.
#. Delete the new security group, as follows:
.. code::
.. code-block:: console
$ nova secgroup-delete GroupName
$ nova secgroup-delete GroupName
For example:
.. code::
.. code-block:: console
$ nova secgroup-delete global_http
$ nova secgroup-delete global_http
Create security group rules for a cluster of instances
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Source Groups are a special, dynamic way of defining the CIDR of allowed
sources. The user specifies a Source Group (Security Group name), and
all the users' other Instances using the specified Source Group are
all the user's other Instances using the specified Source Group are
selected dynamically. This alleviates the need for individual rules to
allow each new member of the cluster.
@ -188,15 +191,15 @@ allow each new member of the cluster.
#. Add a source group, as follows:
.. code::
.. code-block:: console
$ nova secgroup-add-group-rule secGroupName source-group ip-protocol from-port to-port
$ nova secgroup-add-group-rule secGroupName source-group ip-protocol from-port to-port
For example:
.. code::
.. code-block:: console
$ nova secgroup-add-group-rule cluster global_http tcp 22 22
$ nova secgroup-add-group-rule cluster global_http tcp 22 22
The ``cluster`` rule allows ssh access from any other instance that
uses the ``global_http`` group.