[User Guides] Adjust Release notes and remove user-guide-admin files
1.) Adjusts the release notes to clarify that the admin user guide has been reorganised, and the files moved. 2.) Remove user-guide-admin files from the repository. Change-Id: I691339c2c5472fdf88243ab6930c99f95c3533d3 Implements: blueprints user-guide-reorganised
This commit is contained in:
parent
12994d33ba
commit
fa7cadabde
|
@ -6,7 +6,7 @@ declare -A DIRECTORIES=(
|
|||
declare -A BOOKS=(
|
||||
["cs"]="install-guide"
|
||||
["fr"]="install-guide"
|
||||
["ja"]="image-guide user-guide user-guide-admin install-guide networking-guide"
|
||||
["ja"]="image-guide user-guide install-guide networking-guide"
|
||||
)
|
||||
|
||||
# draft books
|
||||
|
|
|
@ -1,30 +0,0 @@
|
|||
[metadata]
|
||||
name = openstackuserguideadmin
|
||||
summary = OpenStack Admin User Guide
|
||||
author = OpenStack
|
||||
author-email = openstack-docs@lists.openstack.org
|
||||
home-page = http://docs.openstack.org/
|
||||
classifier =
|
||||
Environment :: OpenStack
|
||||
Intended Audience :: Information Technology
|
||||
Intended Audience :: System Administrators
|
||||
License :: OSI Approved :: Apache Software License
|
||||
Operating System :: POSIX :: Linux
|
||||
Topic :: Documentation
|
||||
|
||||
[global]
|
||||
setup-hooks =
|
||||
pbr.hooks.setup_hook
|
||||
|
||||
[files]
|
||||
|
||||
[build_sphinx]
|
||||
all_files = 1
|
||||
build-dir = build
|
||||
source-dir = source
|
||||
|
||||
[wheel]
|
||||
universal = 1
|
||||
|
||||
[pbr]
|
||||
warnerrors = True
|
|
@ -1,30 +0,0 @@
|
|||
#!/usr/bin/env python
|
||||
# Copyright (c) 2013 Hewlett-Packard Development Company, L.P.
|
||||
#
|
||||
# Licensed under the Apache License, Version 2.0 (the "License");
|
||||
# you may not use this file except in compliance with the License.
|
||||
# You may obtain a copy of the License at
|
||||
#
|
||||
# http://www.apache.org/licenses/LICENSE-2.0
|
||||
#
|
||||
# Unless required by applicable law or agreed to in writing, software
|
||||
# distributed under the License is distributed on an "AS IS" BASIS,
|
||||
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
||||
# implied.
|
||||
# See the License for the specific language governing permissions and
|
||||
# limitations under the License.
|
||||
|
||||
# THIS FILE IS MANAGED BY THE GLOBAL REQUIREMENTS REPO - DO NOT EDIT
|
||||
import setuptools
|
||||
|
||||
# In python < 2.7.4, a lazy loading of package `pbr` will break
|
||||
# setuptools if some other modules registered functions in `atexit`.
|
||||
# solution from: http://bugs.python.org/issue15881#msg170215
|
||||
try:
|
||||
import multiprocessing # noqa
|
||||
except ImportError:
|
||||
pass
|
||||
|
||||
setuptools.setup(
|
||||
setup_requires=['pbr'],
|
||||
pbr=True)
|
|
@ -1,211 +0,0 @@
|
|||
=================
|
||||
Analyze log files
|
||||
=================
|
||||
|
||||
Use the swift command-line client to analyze log files.
|
||||
|
||||
The swift client is simple to use, scalable, and flexible.
|
||||
|
||||
Use the swift client :option:`-o` or :option:`-output` option to get
|
||||
short answers to questions about logs.
|
||||
|
||||
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.
|
||||
|
||||
Upload and analyze log files
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. This example assumes that ``logtest`` directory contains the
|
||||
following log files.
|
||||
|
||||
.. 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.
|
||||
|
||||
.. 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.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cd logtest
|
||||
|
||||
#. Upload the log files into the ``logtest`` container.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ swift -A http://swift-auth.com:11000/v1.0 -U test:tester -K testing upload logtest *.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
|
||||
|
||||
#. Get statistics for the account.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ swift -A http://swift-auth.com:11000/v1.0 -U test:tester -K testing \
|
||||
-q stat
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Account: AUTH_cd4f57824deb4248a533f2c28bf156d3
|
||||
Containers: 1
|
||||
Objects: 4
|
||||
Bytes: 5888268
|
||||
|
||||
#. Get statistics for the ``logtest`` container.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ swift -A http://swift-auth.com:11000/v1.0 -U test:tester -K testing \
|
||||
stat logtest
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
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 :option:`-o` option and a hyphen (``-``) to get
|
||||
information about an object.
|
||||
|
||||
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``.
|
||||
|
||||
Using the log line format, find the request type in column 9 and the
|
||||
return code in column 12.
|
||||
|
||||
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.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ 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
|
||||
2 DELETE-409
|
||||
723 GET-200
|
||||
142 GET-204
|
||||
74 GET-206
|
||||
80 GET-304
|
||||
34 GET-401
|
||||
5 GET-403
|
||||
18 GET-404
|
||||
166 GET-412
|
||||
2 GET-416
|
||||
50 HEAD-200
|
||||
17 HEAD-204
|
||||
20 HEAD-401
|
||||
8 HEAD-404
|
||||
30 POST-202
|
||||
25 POST-204
|
||||
22 POST-400
|
||||
6 POST-404
|
||||
842 PUT-201
|
||||
2 PUT-202
|
||||
32 PUT-400
|
||||
4 PUT-403
|
||||
4 PUT-404
|
||||
2 PUT-411
|
||||
6 PUT-412
|
||||
6 PUT-413
|
||||
2 PUT-422
|
||||
8 PUT-499
|
||||
|
||||
#. 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 :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-block:: console
|
||||
|
||||
$ for f in `swift -A http://swift-auth.com:11000/v1.0 -U test:tester \
|
||||
-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-block:: console
|
||||
|
||||
2010-11-15-21_access.log - PUTS - 402
|
||||
2010-11-15-22_access.log - PUTS - 1091
|
||||
2010-11-16-21_access.log - PUTS - 892
|
||||
2010-11-16-22_access.log - PUTS - 910
|
||||
|
||||
#. List the object names that begin with a specified 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 :command:`swift download -o -` command.
|
||||
|
||||
#. 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` ; \
|
||||
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-block:: console
|
||||
|
||||
2010-11-15-21_access.log - PUTS - 402
|
||||
2010-11-15-22_access.log - PUTS - 910
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
==============================
|
||||
OpenStack command-line clients
|
||||
==============================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
common/cli_overview.rst
|
||||
common/cli_install_openstack_command_line_clients.rst
|
||||
common/cli_discover_version_number_for_a_client.rst
|
||||
common/cli_set_environment_variables_using_openstack_rc.rst
|
||||
manage_projects_users_and_roles.rst
|
||||
nova_cli_manage_projects_security.rst
|
||||
cli_manage_services.rst
|
||||
common/cli_manage_images.rst
|
||||
common/cli_manage_volumes.rst
|
||||
cli_manage_shares.rst
|
||||
cli_manage_flavors.rst
|
||||
cli_admin_manage_environment.rst
|
||||
cli_set_quotas.rst
|
||||
analyzing-log-files-with-swift-cli.rst
|
||||
cli_cinder_scheduling.rst
|
|
@ -1,16 +0,0 @@
|
|||
================================
|
||||
Manage the OpenStack environment
|
||||
================================
|
||||
|
||||
This section includes tasks specific to the OpenStack environment.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
cli_nova_specify_host.rst
|
||||
cli_nova_numa_libvirt.rst
|
||||
cli_nova_evacuate.rst
|
||||
cli_nova_migrate.rst
|
||||
cli_admin_manage_ip_addresses.rst
|
||||
cli_admin_manage_stacks.rst
|
||||
common/nova_show_usage_statistics_for_hosts_instances.rst
|
|
@ -1,106 +0,0 @@
|
|||
===================
|
||||
Manage IP addresses
|
||||
===================
|
||||
|
||||
Each instance has a private, fixed IP address (assigned when launched)
|
||||
and can also have a public, or floating, address. Private IP addresses
|
||||
are used for communication between instances, and public addresses are
|
||||
used for communication with networks outside the cloud, including the
|
||||
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/>`_.
|
||||
|
||||
- For details on creating public networks using OpenStack Networking
|
||||
(``neutron``), refer to the `OpenStack Cloud Administrator Guide
|
||||
<http://docs.openstack.org/admin-guide-cloud/networking_adv-features.html>`_
|
||||
. No floating IP addresses are created by default in OpenStack Networking.
|
||||
|
||||
As an administrator using legacy networking (``nova-network``), you
|
||||
can use the following bulk commands to list, create, and delete ranges
|
||||
of floating IP addresses. These addresses can then be associated with
|
||||
instances by end users.
|
||||
|
||||
List addresses for all projects
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
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:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova floating-ip-bulk-create [--pool POOL_NAME] [--interface INTERFACE] RANGE_TO_CREATE
|
||||
|
||||
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:
|
||||
|
||||
- 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:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova floating-ip-bulk-delete RANGE_TO_DELETE
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova floating-ip-bulk-delete 192.168.1.56/29
|
|
@ -1,35 +0,0 @@
|
|||
======================================
|
||||
Launch and manage stacks using the CLI
|
||||
======================================
|
||||
|
||||
The Orchestration service provides a template-based
|
||||
orchestration engine for the OpenStack cloud, which
|
||||
can be used to create and manage cloud infrastructure
|
||||
resources such as storage, networking, instances, and
|
||||
applications as a repeatable running environment.
|
||||
|
||||
Templates are used to create stacks, which are collections
|
||||
of resources. For example, a stack might include instances,
|
||||
floating IPs, volumes, security groups, or users.
|
||||
The Orchestration service offers access to all OpenStack
|
||||
core services via a single modular template, with additional
|
||||
orchestration capabilities such as auto-scaling and basic
|
||||
high availability.
|
||||
|
||||
For information about:
|
||||
|
||||
- basic creation and deletion of Orchestration stacks, refer
|
||||
to the `OpenStack End User Guide <http://docs.openstack.org/user-guide/dashboard_stacks.html>`_
|
||||
|
||||
- **heat** CLI commands, see the `OpenStack Command Line Interface Reference
|
||||
<http://docs.openstack.org/cli-reference/heat.html>`_
|
||||
|
||||
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-block:: console
|
||||
|
||||
$ heat action-resume stackID
|
||||
$ heat action-suspend stackID
|
||||
$ heat stack-delete stackID
|
|
@ -1,162 +0,0 @@
|
|||
===================================
|
||||
Manage Block Storage service quotas
|
||||
===================================
|
||||
|
||||
As an administrative user, you can update the OpenStack Block
|
||||
Storage service quotas for a project. You can also update the quota
|
||||
defaults for a new project.
|
||||
|
||||
**Block Storage quotas**
|
||||
|
||||
=================== =============================================
|
||||
Property name Defines the number of
|
||||
=================== =============================================
|
||||
gigabytes Volume gigabytes allowed for each project.
|
||||
snapshots Volume snapshots allowed for each project.
|
||||
volumes Volumes allowed for each project.
|
||||
=================== =============================================
|
||||
|
||||
View Block Storage quotas
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Administrative users can view Block Storage service quotas.
|
||||
|
||||
#. Obtain the project ID.
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ project_id=$(openstack project show -f value -c id PROJECT_NAME)
|
||||
|
||||
#. List the default quotas for a project (tenant):
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder quota-defaults PROJECT_ID
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder quota-defaults $project_id
|
||||
+-----------+-------+
|
||||
| Property | Value |
|
||||
+-----------+-------+
|
||||
| gigabytes | 1000 |
|
||||
| snapshots | 10 |
|
||||
| volumes | 10 |
|
||||
+-----------+-------+
|
||||
|
||||
#. View Block Storage service quotas for a project (tenant):
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder quota-show PROJECT_ID
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder quota-show $project_id
|
||||
+-----------+-------+
|
||||
| Property | Value |
|
||||
+-----------+-------+
|
||||
| gigabytes | 1000 |
|
||||
| snapshots | 10 |
|
||||
| volumes | 10 |
|
||||
+-----------+-------+
|
||||
|
||||
#. Show the current usage of a per-project quota:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder quota-usage PROJECT_ID
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder quota-usage $project_id
|
||||
+-----------+--------+----------+-------+
|
||||
| Type | In_use | Reserved | Limit |
|
||||
+-----------+--------+----------+-------+
|
||||
| gigabytes | 0 | 0 | 1000 |
|
||||
| snapshots | 0 | 0 | 10 |
|
||||
| volumes | 0 | 0 | 15 |
|
||||
+-----------+--------+----------+-------+
|
||||
|
||||
Edit and update Block Storage service quotas
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Administrative users can edit and update Block Storage
|
||||
service quotas.
|
||||
|
||||
#. Clear per-project quota limits.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder quota-delete PROJECT_ID
|
||||
|
||||
|
||||
#. To update a default value for a new project,
|
||||
update the property in the :guilabel:`cinder.quota`
|
||||
section of the ``/etc/cinder/cinder.conf`` file.
|
||||
For more information, see the `Block Storage
|
||||
Configuration Reference <http://docs.openstack.org/mitaka/config-reference/block-storage.html>`_.
|
||||
|
||||
#. To update Block Storage service quotas for an existing project (tenant)
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder quota-update --QUOTA_NAME QUOTA_VALUE PROJECT_ID
|
||||
|
||||
Replace QUOTA_NAME with the quota that is to be updated; NEW_VALUE with the required new value and PROJECT_ID with required project ID
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder quota-update --volumes 15 $project_id
|
||||
$ cinder quota-show $project_id
|
||||
+-----------+-------+
|
||||
| Property | Value |
|
||||
+-----------+-------+
|
||||
| gigabytes | 1000 |
|
||||
| snapshots | 10 |
|
||||
| volumes | 15 |
|
||||
+-----------+-------+
|
||||
|
||||
|
||||
#. Clear per-project quota limits.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder quota-delete PROJECT_ID
|
||||
|
||||
Remove a service
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Determine the binary and host of the service you want to remove.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder service-list
|
||||
+------------------+----------------------+------+---------+-------+----------------------------+-----------------+
|
||||
| Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
|
||||
+------------------+----------------------+------+---------+-------+----------------------------+-----------------+
|
||||
| cinder-scheduler | devstack | nova | enabled | up | 2015-10-13T15:21:48.000000 | - |
|
||||
| cinder-volume | devstack@lvmdriver-1 | nova | enabled | up | 2015-10-13T15:21:52.000000 | - |
|
||||
+------------------+----------------------+------+---------+-------+----------------------------+-----------------+
|
||||
|
||||
#. Disable the service.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder service-disable HOST_NAME BINARY_NAME
|
||||
|
||||
#. Remove the service from the database.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder-manage service remove BINARY_NAME HOST_NAME
|
|
@ -1,52 +0,0 @@
|
|||
===============================
|
||||
Manage Block Storage scheduling
|
||||
===============================
|
||||
|
||||
As an administrative user, you have some control over which volume
|
||||
back end your volumes reside on. You can specify affinity or
|
||||
anti-affinity between two volumes. Affinity between volumes means
|
||||
that they are stored on the same back end, whereas anti-affinity
|
||||
means that they are stored on different back ends.
|
||||
|
||||
For information on how to set up multiple back ends for Cinder,
|
||||
refer to the guide for `Configuring multiple-storage back ends
|
||||
<http://docs.openstack.org/admin-guide-cloud/blockstorage_multi_backend.html>`__.
|
||||
|
||||
Example Usages
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
#. Create new volume on the same back end as Volume_A:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder create --hint same_host=Volume_A-UUID SIZE
|
||||
|
||||
#. Create new volume on a different back end than Volume_A:
|
||||
|
||||
.. 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-block:: console
|
||||
|
||||
$ cinder create --hint same_host=Volume_A-UUID --hint same_host=Volume_B-UUID SIZE
|
||||
|
||||
Or:
|
||||
|
||||
.. 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-block:: console
|
||||
|
||||
$ cinder create --hint different_host=Volume_A-UUID --hint different_host=Volume_B-UUID SIZE
|
||||
|
||||
Or:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ cinder create --hint different_host="[Volume_A-UUID, Volume_B-UUID]" SIZE
|
|
@ -1,155 +0,0 @@
|
|||
============================================
|
||||
Create and manage services and service users
|
||||
============================================
|
||||
|
||||
The Identity service enables you to define services, as
|
||||
follows:
|
||||
|
||||
- Service catalog template. The Identity service acts
|
||||
as a service catalog of endpoints for other OpenStack
|
||||
services. The ``/etc/keystone/default_catalog.templates``
|
||||
template file defines the endpoints for services. When
|
||||
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
|
||||
to the catalog. When you deploy a system for
|
||||
production, use the SQL back end.
|
||||
|
||||
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
|
||||
create a service user for each OpenStack service. For example,
|
||||
create a service user for the Compute, Block Storage, and
|
||||
Networking services.
|
||||
|
||||
To configure the OpenStack services with service users,
|
||||
create a project for all services and create users for each
|
||||
service. Assign the admin role to each service user and
|
||||
project pair. This role enables users to validate tokens and
|
||||
authenticate and authorize other user requests.
|
||||
|
||||
Create a service
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
#. List the available services:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack service list
|
||||
+----------------------------------+----------+------------+
|
||||
| ID | Name | Type |
|
||||
+----------------------------------+----------+------------+
|
||||
| 9816f1faaa7c4842b90fb4821cd09223 | cinder | volume |
|
||||
| 1250f64f31e34dcd9a93d35a075ddbe1 | cinderv2 | volumev2 |
|
||||
| da8cf9f8546b4a428c43d5e032fe4afc | ec2 | ec2 |
|
||||
| 5f105eeb55924b7290c8675ad7e294ae | glance | image |
|
||||
| dcaa566e912e4c0e900dc86804e3dde0 | keystone | identity |
|
||||
| 4a715cfbc3664e9ebf388534ff2be76a | nova | compute |
|
||||
| 1aed4a6cf7274297ba4026cf5d5e96c5 | novav21 | computev21 |
|
||||
| bed063c790634c979778551f66c8ede9 | neutron | network |
|
||||
| 6feb2e0b98874d88bee221974770e372 | s3 | s3 |
|
||||
+----------------------------------+----------+------------+
|
||||
|
||||
#. To create a service, run this command:
|
||||
|
||||
.. 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.
|
||||
- ``service_type``: the service type, such as ``identity``,
|
||||
``compute``, ``network``, ``image``, ``object-store``
|
||||
or any other service identifier string.
|
||||
- ``service_description``: the description of the service.
|
||||
|
||||
For example, to create a ``swift`` service of type
|
||||
``object-store``, run this command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack service create --name swift --description "object store service" object-store
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | object store service |
|
||||
| enabled | True |
|
||||
| id | 84c23f4b942c44c38b9c42c5e517cd9a |
|
||||
| name | swift |
|
||||
| type | object-store |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
#. To get details for a service, run this command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack service show SERVICE_TYPE|SERVICE_NAME|SERVICE_ID
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack service show object-store
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | object store service |
|
||||
| enabled | True |
|
||||
| id | 84c23f4b942c44c38b9c42c5e517cd9a |
|
||||
| name | swift |
|
||||
| type | object-store |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
Create service users
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Create a project for the service users.
|
||||
Typically, this project is named ``service``,
|
||||
but choose any name you like:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack project create service
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | None |
|
||||
| enabled | True |
|
||||
| id | 3e9f3f5399624b2db548d7f871bd5322 |
|
||||
| name | service |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
#. Create service users for the relevant services for your
|
||||
deployment.
|
||||
|
||||
#. Assign the admin role to the user-project pair.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack role add --project service --user SERVICE_USER_NAME admin
|
||||
+-------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------+----------------------------------+
|
||||
| id | 233109e756c1465292f31e7662b429b1 |
|
||||
| name | admin |
|
||||
+-------+----------------------------------+
|
||||
|
||||
Delete a service
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
To delete a specified service, specify its ID.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack service delete SERVICE_TYPE|SERVICE_NAME|SERVICE_ID
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack service delete object-store
|
|
@ -1,149 +0,0 @@
|
|||
==============
|
||||
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
|
||||
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
|
||||
<http://docs.openstack.org/admin-guide-cloud/compute-flavors.html>`_.
|
||||
|
||||
A flavor consists of the following parameters:
|
||||
|
||||
Flavor ID
|
||||
Unique ID (integer or UUID) for the new flavor. If
|
||||
specifying 'auto', a UUID will be automatically generated.
|
||||
|
||||
Name
|
||||
Name for the new flavor.
|
||||
|
||||
VCPUs
|
||||
Number of virtual CPUs to use.
|
||||
|
||||
Memory MB
|
||||
Amount of RAM to use (in megabytes).
|
||||
|
||||
Root Disk GB
|
||||
Amount of disk space (in gigabytes) to use for
|
||||
the root (/) partition.
|
||||
|
||||
Ephemeral Disk GB
|
||||
Amount of disk space (in gigabytes) to use for
|
||||
the ephemeral partition. If unspecified, the value
|
||||
is 0 by default.
|
||||
Ephemeral disks offer machine local disk storage
|
||||
linked to the lifecycle of a VM instance. When a
|
||||
VM is terminated, all data on the ephemeral disk
|
||||
is lost. Ephemeral disks are not included in any
|
||||
snapshots.
|
||||
|
||||
Swap
|
||||
Amount of swap space (in megabytes) to use. If
|
||||
unspecified, the value is 0 by default.
|
||||
|
||||
The default flavors are:
|
||||
|
||||
============ ========= =============== ===============
|
||||
Flavor VCPUs Disk (in GB) RAM (in MB)
|
||||
============ ========= =============== ===============
|
||||
m1.tiny 1 1 512
|
||||
m1.small 1 20 2048
|
||||
m1.medium 2 40 4096
|
||||
m1.large 4 80 8192
|
||||
m1.xlarge 8 160 16384
|
||||
============ ========= =============== ===============
|
||||
|
||||
You can create and manage flavors with the nova
|
||||
**flavor-*** commands provided by the ``python-novaclient``
|
||||
package.
|
||||
|
||||
Create a flavor
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
#. List flavors to show the ID and name, the amount
|
||||
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:
|
||||
|
||||
.. 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:
|
||||
|
||||
.. 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.
|
||||
|
||||
Here is an example with additional optional
|
||||
parameters filled in that creates a public ``extra
|
||||
tiny`` flavor that automatically gets an ID
|
||||
assigned, with 256 MB memory, no disk space, and
|
||||
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):
|
||||
|
||||
.. 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:
|
||||
|
||||
.. 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:
|
||||
|
||||
.. 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``.
|
||||
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:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova help flavor-key
|
||||
|
||||
Delete a flavor
|
||||
~~~~~~~~~~~~~~~
|
||||
Delete a specified flavor, as follows:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova flavor-delete FLAVOR_ID
|
|
@ -1,9 +0,0 @@
|
|||
===============
|
||||
Manage services
|
||||
===============
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
cli_keystone_manage_services.rst
|
||||
cli_nova_manage_services.rst
|
|
@ -1,40 +0,0 @@
|
|||
.. _share:
|
||||
|
||||
=============
|
||||
Manage shares
|
||||
=============
|
||||
|
||||
A share is provided by file storage. You can give access to a share to
|
||||
instances. To create and manage shares, you use ``manila`` client commands.
|
||||
|
||||
Migrate a share
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
As an administrator, you can migrate a share with its data from one
|
||||
location to another in a manner that is transparent to users and
|
||||
workloads.
|
||||
|
||||
Possible use cases for data migration include:
|
||||
|
||||
- Bring down a physical storage device for maintenance without
|
||||
disrupting workloads.
|
||||
|
||||
- Modify the properties of a share.
|
||||
|
||||
- Free up space in a thinly-provisioned back end.
|
||||
|
||||
Migrate a share with the :command:`manila migrate` command, as shown in the
|
||||
following example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ 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.
|
||||
|
||||
.. note::
|
||||
|
||||
If the user is not an administrator, the migration fails.
|
|
@ -1,51 +0,0 @@
|
|||
==================
|
||||
Evacuate instances
|
||||
==================
|
||||
|
||||
If a hardware malfunction or other error causes a cloud compute node to fail,
|
||||
you can evacuate instances to make them available again. You can optionally
|
||||
include the target host on the :command:`evacuate` command. If you omit the
|
||||
host, the scheduler chooses the target host.
|
||||
|
||||
To preserve user data on the server disk, configure shared storage on the
|
||||
target host. When you evacuate the instance, Compute detects whether shared
|
||||
storage is available on the target host. Also, you must validate that the
|
||||
current VM host is not operational. Otherwise, the evacuation fails.
|
||||
|
||||
#. To find a host for the evacuated instance, list all hosts:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova host-list
|
||||
|
||||
#. Evacuate the instance. You can use the :option:`--password PWD` option
|
||||
to pass the instance password to the command. If you do not specify a
|
||||
password, the command generates and prints one after it finishes
|
||||
successfully. The following command evacuates a server from a failed host
|
||||
to HOST_B.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova evacuate EVACUATED_SERVER_NAME HOST_B
|
||||
|
||||
The command rebuilds the instance from the original image or volume and
|
||||
returns a password. The command preserves the original configuration, which
|
||||
includes the instance ID, name, uid, IP address, and so on.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
+-----------+--------------+
|
||||
| Property | Value |
|
||||
+-----------+--------------+
|
||||
| adminPass | kRAJpErnT4xZ |
|
||||
+-----------+--------------+
|
||||
|
||||
#. To preserve the user disk data on the evacuated server, deploy 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 the `OpenStack Cloud Administrator Guide`. The
|
||||
following example does not change the password.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova evacuate EVACUATED_SERVER_NAME HOST_B --on-shared-storage
|
|
@ -1,76 +0,0 @@
|
|||
=======================
|
||||
Manage Compute services
|
||||
=======================
|
||||
You can enable and disable Compute services. The following
|
||||
examples disable and enable the ``nova-compute`` service.
|
||||
|
||||
|
||||
#. List the Compute services:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova service-list
|
||||
+------------------+----------+----------+---------+-------+----------------------------+-----------------+
|
||||
| Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
|
||||
+------------------+----------+----------+---------+-------+----------------------------+-----------------+
|
||||
| nova-conductor | devstack | internal | enabled | up | 2013-10-16T00:56:08.000000 | None |
|
||||
| nova-cert | devstack | internal | enabled | up | 2013-10-16T00:56:09.000000 | None |
|
||||
| nova-compute | devstack | nova | enabled | up | 2013-10-16T00:56:07.000000 | None |
|
||||
| nova-network | devstack | internal | enabled | up | 2013-10-16T00:56:06.000000 | None |
|
||||
| nova-scheduler | devstack | internal | enabled | up | 2013-10-16T00:56:04.000000 | None |
|
||||
| nova-consoleauth | devstack | internal | enabled | up | 2013-10-16T00:56:07.000000 | None |
|
||||
+------------------+----------+----------+---------+-------+----------------------------+-----------------+
|
||||
|
||||
#. Disable a nova service:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova service-disable localhost.localdomain nova-compute --reason 'trial log'
|
||||
+----------+--------------+----------+-------------------+
|
||||
| Host | Binary | Status | Disabled Reason |
|
||||
+----------+--------------+----------+-------------------+
|
||||
| devstack | nova-compute | disabled | Trial log |
|
||||
+----------+--------------+----------+-------------------+
|
||||
|
||||
#. Check the service list:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova service-list
|
||||
+------------------+----------+----------+---------+-------+----------------------------+------------------+
|
||||
| Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
|
||||
+------------------+----------+----------+---------+-------+----------------------------+------------------+
|
||||
| nova-conductor | devstack | internal | enabled | up | 2013-10-16T00:56:48.000000 | None |
|
||||
| nova-cert | devstack | internal | enabled | up | 2013-10-16T00:56:49.000000 | None |
|
||||
| nova-compute | devstack | nova | disabled | up | 2013-10-16T00:56:47.000000 | Trial log |
|
||||
| nova-network | devstack | internal | enabled | up | 2013-10-16T00:56:51.000000 | None |
|
||||
| nova-scheduler | devstack | internal | enabled | up | 2013-10-16T00:56:44.000000 | None |
|
||||
| nova-consoleauth | devstack | internal | enabled | up | 2013-10-16T00:56:47.000000 | None |
|
||||
+------------------+----------+----------+---------+-------+----------------------------+------------------+
|
||||
|
||||
#. Enable the service:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova service-enable localhost.localdomain nova-compute
|
||||
+----------+--------------+---------+
|
||||
| Host | Binary | Status |
|
||||
+----------+--------------+---------+
|
||||
| devstack | nova-compute | enabled |
|
||||
+----------+--------------+---------+
|
||||
|
||||
#. Check the service list:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova service-list
|
||||
+------------------+----------+----------+---------+-------+----------------------------+-----------------+
|
||||
| Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
|
||||
+------------------+----------+----------+---------+-------+----------------------------+-----------------+
|
||||
| nova-conductor | devstack | internal | enabled | up | 2013-10-16T00:57:08.000000 | None |
|
||||
| nova-cert | devstack | internal | enabled | up | 2013-10-16T00:57:09.000000 | None |
|
||||
| nova-compute | devstack | nova | enabled | up | 2013-10-16T00:57:07.000000 | None |
|
||||
| nova-network | devstack | internal | enabled | up | 2013-10-16T00:57:11.000000 | None |
|
||||
| nova-scheduler | devstack | internal | enabled | up | 2013-10-16T00:57:14.000000 | None |
|
||||
| nova-consoleauth | devstack | internal | enabled | up | 2013-10-16T00:57:07.000000 | None |
|
||||
+------------------+----------+----------+---------+-------+----------------------------+-----------------+
|
|
@ -1,78 +0,0 @@
|
|||
===============================================
|
||||
Migrate single instance to another compute host
|
||||
===============================================
|
||||
|
||||
When you want to move an instance from one compute host to another,
|
||||
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:
|
||||
|
||||
.. 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:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova show VM_ID
|
||||
|
||||
#. Now, use the :command:`nova migrate` command.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova migrate VM_ID
|
||||
|
||||
#. To migrate an instance and watch the status, use this example script:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/bin/bash
|
||||
|
||||
# Provide usage
|
||||
usage() {
|
||||
echo "Usage: $0 VM_ID"
|
||||
exit 1
|
||||
}
|
||||
|
||||
[[ $# -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;
|
||||
|
||||
# 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."
|
||||
|
||||
.. 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``
|
||||
file prevents migration for your user:
|
||||
|
||||
``ERROR (Forbidden): Policy doesn't allow compute_extension:admin_actions:migrate
|
||||
to be performed. (HTTP 403)``
|
||||
|
||||
The instance is booted from a new host, but preserves its configuration
|
||||
including its ID, name, any metadata, IP address, and other properties.
|
|
@ -1,24 +0,0 @@
|
|||
=============================================
|
||||
Consider NUMA topology when booting instances
|
||||
=============================================
|
||||
|
||||
NUMA topology can exist on both the physical hardware of the host, and the
|
||||
virtual hardware of the instance. OpenStack Compute uses libvirt to tune
|
||||
instances to take advantage of NUMA topologies. The libvirt driver boot
|
||||
process looks at the NUMA topology field of both the instance and the host it
|
||||
is being booted on, and uses that information to generate an appropriate
|
||||
configuration.
|
||||
|
||||
If the host is NUMA capable, but the instance has not requested a NUMA
|
||||
topology, Compute attempts to pack the instance into a single cell.
|
||||
If this fails, though, Compute will not continue to try.
|
||||
|
||||
If the host is NUMA capable, and the instance has requested a specific NUMA
|
||||
topology, Compute will try to pin the vCPUs of different NUMA cells
|
||||
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 ``nova.conf`` configuration
|
||||
file. For more information about the ``vcpu_pin_set`` parameter, see the
|
||||
Configuration Reference Guide.
|
|
@ -1,36 +0,0 @@
|
|||
=========================================
|
||||
Select hosts where instances are launched
|
||||
=========================================
|
||||
|
||||
With the appropriate permissions, you can select which
|
||||
host instances are launched on and which roles can boot instances
|
||||
on this host.
|
||||
|
||||
#. To select the host where instances are launched, use
|
||||
the :option:`--availability_zone ZONE:HOST` parameter on the
|
||||
:command:`nova boot` command.
|
||||
|
||||
For example:
|
||||
|
||||
.. 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 ``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.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova hypervisor-list
|
||||
+----+---------------------+
|
||||
| ID | Hypervisor hostname |
|
||||
+----+---------------------+
|
||||
| 1 | server2 |
|
||||
| 2 | server3 |
|
||||
| 3 | server4 |
|
||||
+----+---------------------+
|
|
@ -1,299 +0,0 @@
|
|||
=============================
|
||||
Manage Compute service quotas
|
||||
=============================
|
||||
|
||||
As an administrative user, you can use the :command:`nova quota-*`
|
||||
commands, which are provided by the ``python-novaclient``
|
||||
package, to update the Compute service quotas for a specific tenant or
|
||||
tenant user, as well as update the quota defaults for a new tenant.
|
||||
|
||||
**Compute quota descriptions**
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
:widths: 10 40
|
||||
|
||||
* - Quota name
|
||||
- Description
|
||||
* - cores
|
||||
- Number of instance cores (VCPUs) allowed per tenant.
|
||||
* - fixed-ips
|
||||
- Number of fixed IP addresses allowed per tenant. This number
|
||||
must be equal to or greater than the number of allowed
|
||||
instances.
|
||||
* - floating-ips
|
||||
- Number of floating IP addresses allowed per tenant.
|
||||
* - injected-file-content-bytes
|
||||
- Number of content bytes allowed per injected file.
|
||||
* - injected-file-path-bytes
|
||||
- Length of injected file path.
|
||||
* - injected-files
|
||||
- Number of injected files allowed per tenant.
|
||||
* - instances
|
||||
- Number of instances allowed per tenant.
|
||||
* - key-pairs
|
||||
- Number of key pairs allowed per user.
|
||||
* - metadata-items
|
||||
- Number of metadata items allowed per instance.
|
||||
* - ram
|
||||
- Megabytes of instance ram allowed per tenant.
|
||||
* - security-groups
|
||||
- Number of security groups per tenant.
|
||||
* - security-group-rules
|
||||
- Number of rules per security group.
|
||||
|
||||
View and update Compute quotas for a tenant (project)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To view and update default quota values
|
||||
---------------------------------------
|
||||
#. List all default quotas for all tenants:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova quota-defaults
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ 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 |
|
||||
+-----------------------------+-------+
|
||||
|
||||
#. Update a default value for a new tenant.
|
||||
|
||||
.. 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.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ tenant=$(openstack project show -f value -c id TENANT_NAME)
|
||||
|
||||
#. List the currently set quota values for a tenant.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ 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.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ tenant=$(openstack project show -f value -c id TENANT_NAME)
|
||||
|
||||
#. Update a particular quota value.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova quota-update --QUOTA_NAME QUOTA_VALUE TENANT_ID
|
||||
|
||||
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.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ tenantUser=$(openstack user show -f value -c id USER_NAME)
|
||||
|
||||
#. 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)
|
||||
|
||||
#. 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.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ tenantUser=$(openstack user show -f value -c id USER_NAME)
|
||||
|
||||
#. 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)
|
||||
|
||||
#. Update a particular quota value, as follows:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ 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:
|
||||
|
||||
.. 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 |
|
||||
+-------------------------+-------+
|
|
@ -1,54 +0,0 @@
|
|||
=============
|
||||
Manage quotas
|
||||
=============
|
||||
|
||||
To prevent system capacities from being exhausted without
|
||||
notification, you can set up quotas. Quotas are operational
|
||||
limits. For example, the number of gigabytes allowed for each
|
||||
tenant can be controlled so that cloud resources are optimized.
|
||||
Quotas can be enforced at both the tenant (or project)
|
||||
and the tenant-user level.
|
||||
|
||||
Using the command-line interface, you can manage quotas for
|
||||
the OpenStack Compute service, the OpenStack Block Storage service,
|
||||
and the OpenStack Networking service.
|
||||
|
||||
The cloud operator typically changes default values because a
|
||||
tenant requires more than ten volumes or 1 TB on a compute
|
||||
node.
|
||||
|
||||
.. note::
|
||||
|
||||
To view all tenants (projects), run:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ 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::
|
||||
:maxdepth: 2
|
||||
|
||||
cli_set_compute_quotas.rst
|
||||
cli_cinder_quotas.rst
|
||||
networking_advanced_quotas.rst
|
|
@ -1 +0,0 @@
|
|||
../../common
|
|
@ -1,307 +0,0 @@
|
|||
# Licensed under the Apache License, Version 2.0 (the "License");
|
||||
# you may not use this file except in compliance with the License.
|
||||
# You may obtain a copy of the License at
|
||||
#
|
||||
# http://www.apache.org/licenses/LICENSE-2.0
|
||||
#
|
||||
# Unless required by applicable law or agreed to in writing, software
|
||||
# distributed under the License is distributed on an "AS IS" BASIS,
|
||||
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
||||
# implied.
|
||||
# See the License for the specific language governing permissions and
|
||||
# limitations under the License.
|
||||
|
||||
# This file is execfile()d with the current directory set to its
|
||||
# containing dir.
|
||||
#
|
||||
# Note that not all possible configuration values are present in this
|
||||
# autogenerated file.
|
||||
#
|
||||
# All configuration values have a default; values that are commented out
|
||||
# serve to show the default.
|
||||
|
||||
import os
|
||||
# import sys
|
||||
|
||||
|
||||
import openstackdocstheme
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
# sys.path.insert(0, os.path.abspath('.'))
|
||||
|
||||
# -- General configuration ------------------------------------------------
|
||||
|
||||
# If your documentation needs a minimal Sphinx version, state it here.
|
||||
# needs_sphinx = '1.0'
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
# TODO(ajaeger): enable PDF building, for example add 'rst2pdf.pdfbuilder'
|
||||
extensions = []
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
# templates_path = ['_templates']
|
||||
|
||||
# The suffix of source filenames.
|
||||
source_suffix = '.rst'
|
||||
|
||||
# The encoding of source files.
|
||||
# source_encoding = 'utf-8-sig'
|
||||
|
||||
# The master toctree document.
|
||||
master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = u'Admin User Guide'
|
||||
bug_tag = u'admin-user-guide'
|
||||
|
||||
copyright = u'2015-2016, OpenStack contributors'
|
||||
|
||||
# The version info for the project you're documenting, acts as replacement for
|
||||
# |version| and |release|, also used in various other places throughout the
|
||||
# built documents.
|
||||
#
|
||||
# The short X.Y version.
|
||||
version = '1.0.0'
|
||||
# The full version, including alpha/beta/rc tags.
|
||||
release = '1.0.0'
|
||||
|
||||
# A few variables have to be set for the log-a-bug feature.
|
||||
# giturl: The location of conf.py on Git. Must be set manually.
|
||||
# gitsha: The SHA checksum of the bug description. Automatically extracted from git log.
|
||||
# bug_tag: Tag for categorizing the bug. Must be set manually.
|
||||
# These variables are passed to the logabug code via html_context.
|
||||
giturl = u'http://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/user-guide-admin/source'
|
||||
git_cmd = "/usr/bin/git log | head -n1 | cut -f2 -d' '"
|
||||
gitsha = os.popen(git_cmd).read().strip('\n')
|
||||
html_context = {"gitsha": gitsha, "bug_tag": bug_tag,
|
||||
"giturl": giturl}
|
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation
|
||||
# for a list of supported languages.
|
||||
# language = None
|
||||
|
||||
# There are two options for replacing |today|: either, you set today to some
|
||||
# non-false value, then it is used:
|
||||
# today = ''
|
||||
# Else, today_fmt is used as the format for a strftime call.
|
||||
# today_fmt = '%B %d, %Y'
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
exclude_patterns = ['common/get_started_*',
|
||||
'common/dashboard_customizing.rst']
|
||||
|
||||
|
||||
# The reST default role (used for this markup: `text`) to use for all
|
||||
# documents.
|
||||
# default_role = None
|
||||
|
||||
# If true, '()' will be appended to :func: etc. cross-reference text.
|
||||
# add_function_parentheses = True
|
||||
|
||||
# If true, the current module name will be prepended to all description
|
||||
# unit titles (such as .. function::).
|
||||
# add_module_names = True
|
||||
|
||||
# If true, sectionauthor and moduleauthor directives will be shown in the
|
||||
# output. They are ignored by default.
|
||||
# show_authors = False
|
||||
|
||||
# The name of the Pygments (syntax highlighting) style to use.
|
||||
pygments_style = 'sphinx'
|
||||
|
||||
# A list of ignored prefixes for module index sorting.
|
||||
# modindex_common_prefix = []
|
||||
|
||||
# If true, keep warnings as "system message" paragraphs in the built documents.
|
||||
# keep_warnings = False
|
||||
|
||||
|
||||
# -- Options for HTML output ----------------------------------------------
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
html_theme = 'openstackdocs'
|
||||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme
|
||||
# further. For a list of options available for each theme, see the
|
||||
# documentation.
|
||||
# html_theme_options = {}
|
||||
|
||||
# Add any paths that contain custom themes here, relative to this directory.
|
||||
html_theme_path = [openstackdocstheme.get_html_theme_path()]
|
||||
|
||||
# The name for this set of Sphinx documents. If None, it defaults to
|
||||
# "<project> v<release> documentation".
|
||||
# html_title = None
|
||||
|
||||
# A shorter title for the navigation bar. Default is the same as html_title.
|
||||
# html_short_title = None
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top
|
||||
# of the sidebar.
|
||||
# html_logo = None
|
||||
|
||||
# The name of an image file (within the static path) to use as favicon of the
|
||||
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
|
||||
# pixels large.
|
||||
# html_favicon = None
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
# html_static_path = []
|
||||
|
||||
# Add any extra paths that contain custom files (such as robots.txt or
|
||||
# .htaccess) here, relative to this directory. These files are copied
|
||||
# directly to the root of the documentation.
|
||||
# html_extra_path = []
|
||||
|
||||
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
|
||||
# using the given strftime format.
|
||||
# So that we can enable "log-a-bug" links from each output HTML page, this
|
||||
# variable must be set to a format that includes year, month, day, hours and
|
||||
# minutes.
|
||||
html_last_updated_fmt = '%Y-%m-%d %H:%M'
|
||||
|
||||
|
||||
# If true, SmartyPants will be used to convert quotes and dashes to
|
||||
# typographically correct entities.
|
||||
# html_use_smartypants = True
|
||||
|
||||
# Custom sidebar templates, maps document names to template names.
|
||||
# html_sidebars = {}
|
||||
|
||||
# Additional templates that should be rendered to pages, maps page names to
|
||||
# template names.
|
||||
# html_additional_pages = {}
|
||||
|
||||
# If false, no module index is generated.
|
||||
# html_domain_indices = True
|
||||
|
||||
# If false, no index is generated.
|
||||
html_use_index = False
|
||||
|
||||
# If true, the index is split into individual pages for each letter.
|
||||
# html_split_index = False
|
||||
|
||||
# If true, links to the reST sources are added to the pages.
|
||||
# This one is needed for "Report a bug".
|
||||
html_show_sourcelink = False
|
||||
|
||||
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
|
||||
# html_show_sphinx = True
|
||||
|
||||
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
|
||||
# html_show_copyright = True
|
||||
|
||||
# If true, an OpenSearch description file will be output, and all pages will
|
||||
# contain a <link> tag referring to it. The value of this option must be the
|
||||
# base URL from which the finished HTML is served.
|
||||
# html_use_opensearch = ''
|
||||
|
||||
# This is the file name suffix for HTML files (e.g. ".xhtml").
|
||||
# html_file_suffix = None
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'user-guide-admin'
|
||||
|
||||
# If true, publish source files
|
||||
html_copy_source = False
|
||||
|
||||
# -- Options for linkcheck ------------------------------------------------
|
||||
linkcheck_ignore = [r'https://build.opensuse.org']
|
||||
|
||||
# -- Options for LaTeX output ---------------------------------------------
|
||||
|
||||
latex_elements = {
|
||||
# The paper size ('letterpaper' or 'a4paper').
|
||||
# 'papersize': 'letterpaper',
|
||||
|
||||
# The font size ('10pt', '11pt' or '12pt').
|
||||
# 'pointsize': '10pt',
|
||||
|
||||
# Additional stuff for the LaTeX preamble.
|
||||
# 'preamble': '',
|
||||
}
|
||||
|
||||
# Grouping the document tree into LaTeX files. List of tuples
|
||||
# (source start file, target name, title,
|
||||
# author, documentclass [howto, manual, or own class]).
|
||||
latex_documents = [
|
||||
('index', 'UserGuide.tex', u'User Guide',
|
||||
u'OpenStack contributors', 'manual'),
|
||||
]
|
||||
|
||||
# The name of an image file (relative to this directory) to place at the top of
|
||||
# the title page.
|
||||
# latex_logo = None
|
||||
|
||||
# For "manual" documents, if this is true, then toplevel headings are parts,
|
||||
# not chapters.
|
||||
# latex_use_parts = False
|
||||
|
||||
# If true, show page references after internal links.
|
||||
# latex_show_pagerefs = False
|
||||
|
||||
# If true, show URL addresses after external links.
|
||||
# latex_show_urls = False
|
||||
|
||||
# Documents to append as an appendix to all manuals.
|
||||
# latex_appendices = []
|
||||
|
||||
# If false, no module index is generated.
|
||||
# latex_domain_indices = True
|
||||
|
||||
|
||||
# -- Options for manual page output ---------------------------------------
|
||||
|
||||
# One entry per manual page. List of tuples
|
||||
# (source start file, name, description, authors, manual section).
|
||||
man_pages = [
|
||||
('index', 'userguide', u'User Guide',
|
||||
[u'OpenStack contributors'], 1)
|
||||
]
|
||||
|
||||
# If true, show URL addresses after external links.
|
||||
# man_show_urls = False
|
||||
|
||||
|
||||
# -- Options for Texinfo output -------------------------------------------
|
||||
|
||||
# Grouping the document tree into Texinfo files. List of tuples
|
||||
# (source start file, target name, title, author,
|
||||
# dir menu entry, description, category)
|
||||
texinfo_documents = [
|
||||
('index', 'UserGuide', u'User Guide',
|
||||
u'OpenStack contributors', 'UserGuide',
|
||||
'This guide shows OpenStack end users how to create and manage resources '
|
||||
'in an OpenStack cloud with the OpenStack dashboard and OpenStack client '
|
||||
'commands.', 'Miscellaneous'),
|
||||
]
|
||||
|
||||
# Documents to append as an appendix to all manuals.
|
||||
# texinfo_appendices = []
|
||||
|
||||
# If false, no module index is generated.
|
||||
# texinfo_domain_indices = True
|
||||
|
||||
# How to display URL addresses: 'footnote', 'no', or 'inline'.
|
||||
# texinfo_show_urls = 'footnote'
|
||||
|
||||
# If true, do not generate a @detailmenu in the "Top" node's menu.
|
||||
# texinfo_no_detailmenu = False
|
||||
|
||||
# -- Options for Internationalization output ------------------------------
|
||||
locale_dirs = ['locale/']
|
||||
|
||||
# -- Options for PDF output --------------------------------------------------
|
||||
|
||||
pdf_documents = [
|
||||
('index-admin', u'AdminUserGuide', u'Admin User Guide',
|
||||
u'OpenStack contributors')
|
||||
]
|
|
@ -1,25 +0,0 @@
|
|||
===================
|
||||
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
|
||||
the dashboard to perform end user tasks, see the `OpenStack End User
|
||||
Guide <http://docs.openstack.org/user-guide/>`__.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
common/log_in_dashboard.rst
|
||||
|
||||
dashboard_manage_images.rst
|
||||
dashboard_admin_manage_roles.rst
|
||||
dashboard_manage_instances.rst
|
||||
dashboard_manage_flavors.rst
|
||||
dashboard_manage_volumes.rst
|
||||
dashboard_manage_shares.rst
|
||||
dashboard_set_quotas.rst
|
||||
dashboard_manage_resources.rst
|
||||
dashboard_manage_host_aggregates.rst
|
||||
dashboard_admin_manage_stacks.rst
|
|
@ -1,59 +0,0 @@
|
|||
=======================
|
||||
Create and manage roles
|
||||
=======================
|
||||
|
||||
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 ``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
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
#. On the :guilabel:`Admin` tab, click the :guilabel:`Roles` category.
|
||||
#. Click the :guilabel:`Create Role` button.
|
||||
|
||||
In the :guilabel:`Create Role` window, enter a name for the role.
|
||||
#. Click the :guilabel:`Create Role` button to confirm your changes.
|
||||
|
||||
Edit a role
|
||||
~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
#. On the :guilabel:`Admin` tab, click the :guilabel:`Roles` category.
|
||||
#. Click the :guilabel:`Edit` button.
|
||||
|
||||
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.
|
||||
|
||||
Delete a role
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
#. On the :guilabel:`Admin` tab, click the :guilabel:`Roles` category.
|
||||
#. Select the role you want to delete and click the :guilabel:`Delete
|
||||
Roles` button.
|
||||
#. In the :guilabel:`Confirm Delete Roles` window, click :guilabel:`Delete
|
||||
Roles` to confirm the deletion.
|
||||
|
||||
You cannot undo this action.
|
|
@ -1,33 +0,0 @@
|
|||
============================================
|
||||
Launch and manage stacks using the Dashboard
|
||||
============================================
|
||||
|
||||
The Orchestration service provides a template-based
|
||||
orchestration engine for the OpenStack cloud. Orchestration
|
||||
services create and manage cloud infrastructure
|
||||
resources such as storage, networking, instances, and
|
||||
applications as a repeatable running environment.
|
||||
|
||||
Administrators use templates to create stacks, which are
|
||||
collections of resources. For example, a stack might
|
||||
include instances, floating IPs, volumes,
|
||||
security groups, or users. The Orchestration service
|
||||
offers access to all OpenStack
|
||||
core services via a single modular template, with additional
|
||||
orchestration capabilities such as auto-scaling and basic
|
||||
high availability.
|
||||
|
||||
For information about:
|
||||
|
||||
* 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.
|
||||
|
||||
* the basic creation and deletion of Orchestration stacks, refer to
|
||||
the `OpenStack End User Guide
|
||||
<http://docs.openstack.org/user-guide/dashboard_stacks.html>`__.
|
||||
|
|
@ -1,161 +0,0 @@
|
|||
==============
|
||||
Manage flavors
|
||||
==============
|
||||
|
||||
In OpenStack, a flavor defines the compute, memory, and storage
|
||||
capacity of a virtual server, also known as an instance. As an
|
||||
administrative user, you can create, edit, and delete flavors.
|
||||
|
||||
The following table lists the default flavors.
|
||||
|
||||
============ ========= =============== =============
|
||||
Flavor VCPUs Disk (in GB) RAM (in MB)
|
||||
============ ========= =============== =============
|
||||
m1.tiny 1 1 512
|
||||
m1.small 1 20 2048
|
||||
m1.medium 2 40 4096
|
||||
m1.large 4 80 8192
|
||||
m1.xlarge 8 160 16384
|
||||
============ ========= =============== =============
|
||||
|
||||
Create flavors
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from
|
||||
the drop-down list.
|
||||
#. In the :guilabel:`Admin` tab, open the :guilabel:`System`
|
||||
tab and click the :guilabel:`Flavors` category.
|
||||
#. Click :guilabel:`Create Flavor`.
|
||||
#. In the :guilabel:`Create Flavor` window, enter or select the
|
||||
parameters for the flavor in the :guilabel:`Flavor Information` tab.
|
||||
|
||||
.. figure:: figures/create_flavor.png
|
||||
|
||||
**Dashboard — Create Flavor**
|
||||
|
||||
========================= =======================================
|
||||
**Name** Enter the flavor name.
|
||||
**ID** Unique ID (integer or UUID) for the
|
||||
new flavor. If specifying 'auto', a
|
||||
UUID will be automatically generated.
|
||||
**VCPUs** Enter the number of virtual CPUs to
|
||||
use.
|
||||
**RAM (MB)** Enter the amount of RAM to use, in
|
||||
megabytes.
|
||||
**Root Disk (GB)** Enter the amount of disk space in
|
||||
gigabytes to use for the root (/)
|
||||
partition.
|
||||
**Ephemeral Disk (GB)** Enter the amount of disk space in
|
||||
gigabytes to use for the ephemeral
|
||||
partition. If unspecified, the value
|
||||
is 0 by default.
|
||||
|
||||
Ephemeral disks offer machine local
|
||||
disk storage linked to the lifecycle
|
||||
of a VM instance. When a VM is
|
||||
terminated, all data on the ephemeral
|
||||
disk is lost. Ephemeral disks are not
|
||||
included in any snapshots.
|
||||
**Swap Disk (MB)** Enter the amount of swap space (in
|
||||
megabytes) to use. If unspecified,
|
||||
the default is 0.
|
||||
========================= =======================================
|
||||
|
||||
#. In the :guilabel:`Flavor Access` tab, you can control access to
|
||||
the flavor by moving projects from the :guilabel:`All Projects`
|
||||
column to the :guilabel:`Selected Projects` column.
|
||||
|
||||
Only projects in the :guilabel:`Selected Projects` column can
|
||||
use the flavor. If there are no projects in the right column,
|
||||
all projects can use the flavor.
|
||||
#. Click :guilabel:`Create Flavor`.
|
||||
|
||||
Update flavors
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
#. In the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Flavors` category.
|
||||
#. Select the flavor that you want to edit. Click :guilabel:`Edit
|
||||
Flavor`.
|
||||
#. In the :guilabel:`Edit Flavor` window, you can change the flavor
|
||||
name, VCPUs, RAM, root disk, ephemeral disk, and swap disk values.
|
||||
#. Click :guilabel:`Save`.
|
||||
|
||||
Update Metadata
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
#. In the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Flavors` category.
|
||||
#. Select the flavor that you want to update. In the drop-down
|
||||
list, click :guilabel:`Update Metadata` or click :guilabel:`No` or
|
||||
:guilabel:`Yes` in the :guilabel:`Metadata` column.
|
||||
#. In the :guilabel:`Update Flavor Metadata` window, you can customize
|
||||
some metadata keys, then add it to this flavor and set them values.
|
||||
#. Click :guilabel:`Save`.
|
||||
|
||||
**Optional metadata keys**
|
||||
|
||||
+-------------------------------+-------------------------------+
|
||||
| | quota:cpu_shares |
|
||||
| +-------------------------------+
|
||||
| **CPU limits** | quota:cpu_period |
|
||||
| +-------------------------------+
|
||||
| | quota:cpu_limit |
|
||||
| +-------------------------------+
|
||||
| | quota:cpu_reservation |
|
||||
| +-------------------------------+
|
||||
| | quota:cpu_quota |
|
||||
+-------------------------------+-------------------------------+
|
||||
| | quota:disk_read_bytes_sec |
|
||||
| +-------------------------------+
|
||||
| **Disk tuning** | quota:disk_read_iops_sec |
|
||||
| +-------------------------------+
|
||||
| | quota:disk_write_bytes_sec |
|
||||
| +-------------------------------+
|
||||
| | quota:disk_write_iops_sec |
|
||||
| +-------------------------------+
|
||||
| | quota:disk_total_bytes_sec |
|
||||
| +-------------------------------+
|
||||
| | quota:disk_total_iops_sec |
|
||||
+-------------------------------+-------------------------------+
|
||||
| | quota:vif_inbound_average |
|
||||
| +-------------------------------+
|
||||
| **Bandwidth I/O** | quota:vif_inbound_burst |
|
||||
| +-------------------------------+
|
||||
| | quota:vif_inbound_peak |
|
||||
| +-------------------------------+
|
||||
| | quota:vif_outbound_average |
|
||||
| +-------------------------------+
|
||||
| | quota:vif_outbound_burst |
|
||||
| +-------------------------------+
|
||||
| | quota:vif_outbound_peak |
|
||||
+-------------------------------+-------------------------------+
|
||||
| **Watchdog behavior** | hw:watchdog_action |
|
||||
+-------------------------------+-------------------------------+
|
||||
| | hw_rng:allowed |
|
||||
| +-------------------------------+
|
||||
| **Random-number generator** | hw_rng:rate_bytes |
|
||||
| +-------------------------------+
|
||||
| | hw_rng:rate_period |
|
||||
+-------------------------------+-------------------------------+
|
||||
|
||||
For information about supporting metadata keys, see the
|
||||
`OpenStack Cloud Administrator Guide
|
||||
<http://docs.openstack.org/admin-guide-cloud/compute-flavors.html>`__.
|
||||
|
||||
Delete flavors
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
#. In the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Flavors` category.
|
||||
#. Select the flavors that you want to delete.
|
||||
#. Click :guilabel:`Delete Flavors`.
|
||||
#. In the :guilabel:`Confirm Delete Flavors` window, click
|
||||
:guilabel:`Delete Flavors` to confirm the deletion. You cannot
|
||||
undo this action.
|
|
@ -1,77 +0,0 @@
|
|||
=================================
|
||||
Create and manage host aggregates
|
||||
=================================
|
||||
|
||||
Host aggregates enable administrative users to assign key-value pairs to
|
||||
groups of machines.
|
||||
|
||||
Each node can have multiple aggregates and each aggregate can have
|
||||
multiple key-value pairs. You can assign the same key-value pair to
|
||||
multiple aggregates.
|
||||
|
||||
The scheduler uses this information to make scheduling decisions.
|
||||
For information, see
|
||||
`Scheduling <http://docs.openstack.org/mitaka/config-reference/compute/scheduler.html>`__.
|
||||
|
||||
To create a host aggregate
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab and click
|
||||
the :guilabel:`Host Aggregates` category.
|
||||
|
||||
#. Click :guilabel:`Create Host Aggregate`.
|
||||
|
||||
#. In the :guilabel:`Create Host Aggregate` dialog box, enter or select the
|
||||
following values on the :guilabel:`Host Aggregate Information` tab:
|
||||
|
||||
- :guilabel:`Name`: The host aggregate name.
|
||||
|
||||
- :guilabel:`Availability Zone`: The cloud provider defines the default
|
||||
availability zone, such as ``us-west``, ``apac-south``, or
|
||||
``nova``. You can target the host aggregate, as follows:
|
||||
|
||||
- When the host aggregate is exposed as an availability zone,
|
||||
select the availability zone when you launch an instance.
|
||||
|
||||
- When the host aggregate is not exposed as an availability zone,
|
||||
select a flavor and its extra specs to target the host
|
||||
aggregate.
|
||||
|
||||
#. Assign hosts to the aggregate using the :guilabel:`Manage Hosts within
|
||||
Aggregate` tab in the same dialog box.
|
||||
|
||||
To assign a host to the aggregate, click **+** for the host. The host
|
||||
moves from the :guilabel:`All available hosts` list to the
|
||||
:guilabel:`Selected hosts` list.
|
||||
|
||||
You can add one host to one or more aggregates. To add a host to an
|
||||
existing aggregate, edit the aggregate.
|
||||
|
||||
To manage host aggregates
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab and click
|
||||
the :guilabel:`Host Aggregates` category.
|
||||
|
||||
- To edit host aggregates, select the host aggregate that you want
|
||||
to edit. Click :guilabel:`Edit Host Aggregate`.
|
||||
|
||||
In the :guilabel:`Edit Host Aggregate` dialog box, you can change the
|
||||
name and availability zone for the aggregate.
|
||||
|
||||
- To manage hosts, locate the host aggregate that you want to edit
|
||||
in the table. Click :guilabel:`More` and select :guilabel:`Manage Hosts`.
|
||||
|
||||
In the :guilabel:`Add/Remove Hosts to Aggregate` dialog box,
|
||||
click **+** to assign a host to an aggregate. Click **-** to
|
||||
remove a host that is assigned to an aggregate.
|
||||
|
||||
- To delete host aggregates, locate the host aggregate that you want
|
||||
to edit in the table. Click :guilabel:`More` and select
|
||||
:guilabel:`Delete Host Aggregate`.
|
|
@ -1,121 +0,0 @@
|
|||
========================
|
||||
Create and manage images
|
||||
========================
|
||||
|
||||
As an administrative user, you can create and manage images
|
||||
for the projects to which you belong. You can also create
|
||||
and manage images for users in all projects to which you have
|
||||
access.
|
||||
|
||||
To create and manage images in specified projects as an end
|
||||
user, see the `upload and manage images with Dashboard in
|
||||
OpenStack End User Guide
|
||||
<http://docs.openstack.org/user-guide/dashboard_manage_images.html>`_
|
||||
and `manage images with CLI in OpenStack End User Guide
|
||||
<http://docs.openstack.org/user-guide/common/cli_manage_images.html>`_ .
|
||||
|
||||
To create and manage images as an administrator for other
|
||||
users, use the following procedures.
|
||||
|
||||
Create images
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
For details about image creation, see the `Virtual Machine Image
|
||||
Guide <http://docs.openstack.org/image-guide/>`_.
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Images` category. The images that you
|
||||
can administer for cloud users appear on this page.
|
||||
#. Click :guilabel:`Create Image`, which opens the
|
||||
:guilabel:`Create An Image` window.
|
||||
|
||||
.. figure:: figures/create_image.png
|
||||
|
||||
**Figure Dashboard — Create Image**
|
||||
|
||||
#. In the :guilabel:`Create An Image` window, enter or select the
|
||||
following values:
|
||||
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Name` | Enter a name for the image. |
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Description` | Enter a brief description of |
|
||||
| | the image. |
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Image Source` | Choose the image source from |
|
||||
| | the dropdown list. Your choices |
|
||||
| | are :guilabel:`Image Location` |
|
||||
| | and :guilabel:`Image File`. |
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Image File` or | Based on your selection, there |
|
||||
| :guilabel:`Image Location` | is an :guilabel:`Image File` or |
|
||||
| | :guilabel:`Image Location` |
|
||||
| | field. You can include the |
|
||||
| | location URL or browse for the |
|
||||
| | image file on your file system |
|
||||
| | and add it. |
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Kernel` | Select the kernel to boot an |
|
||||
| | AMI-style image. |
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Ramdisk` | Select the ramdisk to boot an |
|
||||
| | AMI-style image. |
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Format` | Select the image format. |
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Architecture` | Specify the architecture. For |
|
||||
| | example, ``i386`` for a 32-bit |
|
||||
| | architecture or ``x86_64`` for |
|
||||
| | a 64-bit architecture. |
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Minimum Disk (GB)` | Leave this field empty. |
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Minimum RAM (MB)` | Leave this field empty. |
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Copy Data` | Specify this option to copy |
|
||||
| | image data to the Image service.|
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Public` | Select this option to make the |
|
||||
| | image public to all users. |
|
||||
+-------------------------------+---------------------------------+
|
||||
| :guilabel:`Protected` | Select this option to ensure |
|
||||
| | that only users with |
|
||||
| | permissions can delete it. |
|
||||
+-------------------------------+---------------------------------+
|
||||
|
||||
#. Click :guilabel:`Create Image`.
|
||||
|
||||
The image is queued to be uploaded. It might take several minutes
|
||||
before the status changes from ``Queued`` to ``Active``.
|
||||
|
||||
Update images
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Images` category.
|
||||
#. Select the images that you want to edit. Click :guilabel:`Edit Image`.
|
||||
#. In the :guilabel:`Update Image` window, you can change the image name.
|
||||
|
||||
Select the :guilabel:`Public` check box to make the image public.
|
||||
Clear this check box to make the image private. You cannot change
|
||||
the :guilabel:`Kernel ID`, :guilabel:`Ramdisk ID`, or
|
||||
:guilabel:`Architecture` attributes for an image.
|
||||
#. Click :guilabel:`Update Image`.
|
||||
|
||||
Delete images
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
#. On the :guilabel:`Admin tab`, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Images` category.
|
||||
#. Select the images that you want to delete.
|
||||
#. Click :guilabel:`Delete Images`.
|
||||
#. In the :guilabel:`Confirm Delete Images` window, click :guilabel:`Delete
|
||||
Images` to confirm the deletion.
|
||||
|
||||
You cannot undo this action.
|
|
@ -1,77 +0,0 @@
|
|||
================
|
||||
Manage instances
|
||||
================
|
||||
|
||||
As an administrative user, you can manage instances for users in various
|
||||
projects. You can view, terminate, edit, perform a soft or hard reboot,
|
||||
create a snapshot from, and migrate instances. You can also view the
|
||||
logs for instances or launch a VNC console for an instance.
|
||||
|
||||
For information about using the Dashboard to launch instances as an end
|
||||
user, see the `OpenStack End User Guide <http://docs.openstack.org/user-guide/dashboard_launch_instances.html>`__.
|
||||
|
||||
Create instance snapshots
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Instances` category.
|
||||
|
||||
#. Select an instance to create a snapshot from it. From the
|
||||
:guilabel:`Actions` drop-down list, select :guilabel:`Create Snapshot`.
|
||||
|
||||
#. In the :guilabel:`Create Snapshot` window, enter a name for the snapshot.
|
||||
|
||||
#. Click :guilabel:`Create Snapshot`. The Dashboard shows the instance snapshot
|
||||
in the :guilabel:`Images` category.
|
||||
|
||||
#. To launch an instance from the snapshot, select the snapshot and
|
||||
click :guilabel:`Launch Instance`. For information about launching
|
||||
instances, see the
|
||||
`OpenStack End User Guide <http://docs.openstack.org/user-guide/dashboard_launch_instances.html>`__.
|
||||
|
||||
Control the state of an instance
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Instances` category.
|
||||
|
||||
#. Select the instance for which you want to change the state.
|
||||
|
||||
#. From the drop-down list in the :guilabel:`Actions` column,
|
||||
select the state.
|
||||
|
||||
Depending on the current state of the instance, you can perform various
|
||||
actions on the instance. For example, pause, un-pause, suspend, resume,
|
||||
soft or hard reboot, or terminate (actions in red are dangerous).
|
||||
|
||||
.. figure:: figures/change_instance_state.png
|
||||
:width: 100%
|
||||
|
||||
**Figure Dashboard — Instance Actions**
|
||||
|
||||
|
||||
Track usage
|
||||
~~~~~~~~~~~
|
||||
|
||||
Use the :guilabel:`Overview` category to track usage of instances
|
||||
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 select the :guilabel:`admin` project from the
|
||||
drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Overview` category.
|
||||
|
||||
#. Select a month and click :guilabel:`Submit` to query the instance usage for
|
||||
that month.
|
||||
|
||||
#. Click :guilabel:`Download CSV Summary` to download a CSV summary.
|
|
@ -1,10 +0,0 @@
|
|||
====================
|
||||
View cloud resources
|
||||
====================
|
||||
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
dashboard_manage_services.rst
|
||||
dashboard_view_cloud_resources.rst
|
|
@ -1,37 +0,0 @@
|
|||
=========================
|
||||
View services information
|
||||
=========================
|
||||
|
||||
As an administrative user, you can view information for OpenStack services.
|
||||
|
||||
#. Log in to the dashboard and select the
|
||||
:guilabel:`admin` project from the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, click the :guilabel:`System Information`
|
||||
category.
|
||||
|
||||
View the following information on these tabs:
|
||||
|
||||
* :guilabel:`Services`:
|
||||
Displays the internal name and the public OpenStack name
|
||||
for each service, the host on which the service runs,
|
||||
and whether or not the service is enabled.
|
||||
|
||||
* :guilabel:`Compute Services`:
|
||||
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
|
||||
and zone are listed for each service, as well as its
|
||||
activation status.
|
||||
|
||||
* :guilabel:`Network Agents`:
|
||||
Displays the network agents active within the cluster, such as L3 and
|
||||
DHCP agents, and the status of each agent.
|
||||
|
||||
* :guilabel:`Orchestration Services`:
|
||||
Displays information specific to the Orchestration service. Name,
|
||||
engine id, host and topic are listed for each service, as well as its
|
||||
activation status.
|
|
@ -1,149 +0,0 @@
|
|||
=============================
|
||||
Manage shares and share types
|
||||
=============================
|
||||
|
||||
Shares are file storage that instances can have access to. Users can
|
||||
allow or deny a running instance to have access to a share at any time.
|
||||
For information about using the dashboard to create and manage shares as
|
||||
an end user, see the
|
||||
`OpenStack End User Guide <http://docs.openstack.org/user-guide/dashboard_manage_shares.html>`_.
|
||||
|
||||
As an administrative user, you can manage shares and share types for users
|
||||
in various projects. You can create and delete share types, and you can view
|
||||
and delete shares.
|
||||
|
||||
.. _create-a-share-type:
|
||||
|
||||
Create a share type
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin`
|
||||
project from the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Shares` category.
|
||||
|
||||
#. Click the :guilabel:`Share Types` tab, and click
|
||||
:guilabel:`Create Share Type` button. In the
|
||||
:guilabel:`Create Share Type` window, enter or select the
|
||||
following values.
|
||||
|
||||
:guilabel:`Name`: Enter a name for the share type.
|
||||
|
||||
:guilabel:`Driver handles share servers`: Choose True or False
|
||||
|
||||
:guilabel:`Extra specs`: To add extra specs, use key=value.
|
||||
|
||||
#. Click :guilabel:`Create Share Type` button to confirm your changes.
|
||||
|
||||
.. note::
|
||||
|
||||
A message indicates whether the action succeeded.
|
||||
|
||||
Update share type
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from
|
||||
the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Shares` category.
|
||||
|
||||
#. Click the :guilabel:`Share Types` tab, select the share type
|
||||
that you want to update.
|
||||
|
||||
#. Select :guilabel:`Update Share Type` from Actions.
|
||||
|
||||
#. In the :guilabel:`Update Share Type` window, update extra specs.
|
||||
|
||||
:guilabel:`Extra specs`: To add extra specs, use key=value.
|
||||
To unset extra specs, use key.
|
||||
|
||||
#. Click :guilabel:`Update Share Type` button to confirm your changes.
|
||||
|
||||
.. note::
|
||||
|
||||
A message indicates whether the action succeeded.
|
||||
|
||||
Delete share types
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When you delete a share type, shares of that type are not deleted.
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from
|
||||
the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Shares` category.
|
||||
|
||||
#. Click the :guilabel:`Share Types` tab, select the share type
|
||||
or types that you want to delete.
|
||||
|
||||
#. Click :guilabel:`Delete Share Types` button.
|
||||
|
||||
#. 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.
|
||||
|
||||
Delete shares
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project
|
||||
from the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Shares` category.
|
||||
|
||||
#. Select the share or shares that you want to delete.
|
||||
|
||||
#. Click :guilabel:`Delete Shares` button.
|
||||
|
||||
#. 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.
|
||||
|
||||
Delete share server
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project
|
||||
from the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Share Servers` category.
|
||||
|
||||
#. Select the share that you want to delete.
|
||||
|
||||
#. Click :guilabel:`Delete Share Server` button.
|
||||
|
||||
#. 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.
|
||||
|
||||
Delete share networks
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project
|
||||
from the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Share Networks` category.
|
||||
|
||||
#. Select the share network or share networks that you want to delete.
|
||||
|
||||
#. Click :guilabel:`Delete Share Networks` button.
|
||||
|
||||
#. 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.
|
|
@ -1,161 +0,0 @@
|
|||
===============================
|
||||
Manage volumes and volume types
|
||||
===============================
|
||||
|
||||
Volumes are the Block Storage devices that you attach to instances to enable
|
||||
persistent storage. Users can attach a volume to a running instance or detach
|
||||
a volume and attach it to another instance at any time. For information about
|
||||
using the dashboard to create and manage volumes as an end user, see the
|
||||
`OpenStack End User Guide <http://docs.openstack.org/user-guide/dashboard_manage_volumes.html>`_.
|
||||
|
||||
As an administrative user, you can manage volumes and volume types for users
|
||||
in various projects. You can create and delete volume types, and you can view
|
||||
and delete volumes. Note that a volume can be encrypted by using the steps
|
||||
outlined below.
|
||||
|
||||
.. _create-a-volume-type:
|
||||
|
||||
Create a volume type
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin`
|
||||
project from the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Volumes` category.
|
||||
|
||||
#. Click the :guilabel:`Volume Types` tab, and click
|
||||
:guilabel:`Create Volume Type` button. In the
|
||||
:guilabel:`Create Volume Type` window, enter a name for the volume type.
|
||||
|
||||
#. Click :guilabel:`Create Volume Type` button to confirm your changes.
|
||||
|
||||
.. note::
|
||||
|
||||
A message indicates whether the action succeeded.
|
||||
|
||||
Create an encrypted volume type
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Create a volume type using the steps above for :ref:`create-a-volume-type`.
|
||||
|
||||
#. Click :guilabel:`Create Encryption` in the Actions column of the newly
|
||||
created volume type.
|
||||
|
||||
#. Configure the encrypted volume by setting the parameters below from
|
||||
available options (see table):
|
||||
|
||||
Provider
|
||||
Specifies the class responsible for configuring the encryption.
|
||||
Control Location
|
||||
Specifies whether the encryption is from the front end (nova) or the
|
||||
back end (cinder).
|
||||
Cipher
|
||||
Specifies the encryption algorithm.
|
||||
Key Size (bits)
|
||||
Specifies the encryption key size.
|
||||
|
||||
#. Click :guilabel:`Create Volume Type Encryption`.
|
||||
|
||||
.. figure:: figures/create_volume_type_encryption.png
|
||||
|
||||
**Encryption Options**
|
||||
|
||||
The table below provides a few alternatives available for creating encrypted
|
||||
volumes.
|
||||
|
||||
+--------------------+-----------------------+----------------------------+
|
||||
| Encryption | Parameter | Comments |
|
||||
| parameters | options | |
|
||||
+====================+=======================+============================+
|
||||
| Provider |nova.volume.encryptors.|Allows easier import and |
|
||||
| |luks.LuksEncryptor |migration of imported |
|
||||
| |(Recommended) |encrypted volumes, and |
|
||||
| | |allows access key to be |
|
||||
| | |changed without |
|
||||
| | |re-encrypting the volume |
|
||||
+ +-----------------------+----------------------------+
|
||||
| |nova.volume.encryptors.|Less disk overhead than |
|
||||
| |cryptsetup. |LUKS |
|
||||
| |CryptsetupEncryptor | |
|
||||
+--------------------+-----------------------+----------------------------+
|
||||
| Control Location | front-end |The encryption occurs within|
|
||||
| | (Recommended) |nova so that the data |
|
||||
| | |transmitted over the network|
|
||||
| | |is encrypted |
|
||||
| | | |
|
||||
+ +-----------------------+----------------------------+
|
||||
| | back-end |This could be selected if a |
|
||||
| | |cinder plug-in supporting |
|
||||
| | |an encrypted back-end block |
|
||||
| | |storage device becomes |
|
||||
| | |available in the future. |
|
||||
| | |TLS or other network |
|
||||
| | |encryption would also be |
|
||||
| | |needed to protect data as it|
|
||||
| | |traverses the network |
|
||||
+--------------------+-----------------------+----------------------------+
|
||||
| Cipher | aes-xts-plain64 |See NIST reference below |
|
||||
| | (Recommended) |to see advantages* |
|
||||
+ +-----------------------+----------------------------+
|
||||
| | aes-cbc-essiv |Note: On the command line, |
|
||||
| | |type 'cryptsetup benchmark' |
|
||||
| | |for additional options |
|
||||
+--------------------+-----------------------+----------------------------+
|
||||
| Key Size (bits)| 512 (Recommended for |Using this selection for |
|
||||
| | aes-xts-plain64. 256 |aes-xts, the underlying key |
|
||||
| | should be used for |size would only be 256-bits*|
|
||||
| | aes-cbc-essiv) | |
|
||||
+ +-----------------------+----------------------------+
|
||||
| | 256 |Using this selection for |
|
||||
| | |aes-xts, the underlying key |
|
||||
| | |size would only be 128-bits*|
|
||||
+--------------------+-----------------------+----------------------------+
|
||||
|
||||
`*` Source `NIST SP 800-38E <http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf>`_
|
||||
|
||||
Delete volume types
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When you delete a volume type, volumes of that type are not deleted.
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project from
|
||||
the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Volumes` category.
|
||||
|
||||
#. Click the :guilabel:`Volume Types` tab, select the volume type
|
||||
or types that you want to delete.
|
||||
|
||||
#. Click :guilabel:`Delete Volume Types` button.
|
||||
|
||||
#. 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.
|
||||
|
||||
Delete volumes
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
When you delete an instance, the data of its attached volumes is not
|
||||
destroyed.
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project
|
||||
from the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Volumes` category.
|
||||
|
||||
#. Select the volume or volumes that you want to delete.
|
||||
|
||||
#. Click :guilabel:`Delete Volumes` button.
|
||||
|
||||
#. 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.
|
|
@ -1,115 +0,0 @@
|
|||
.. _dashboard-set-quotas:
|
||||
|
||||
======================
|
||||
View and manage quotas
|
||||
======================
|
||||
|
||||
.. |nbsp| unicode:: 0xA0 .. nbsp
|
||||
:trim:
|
||||
|
||||
To prevent system capacities from being exhausted without notification,
|
||||
you can set up quotas. Quotas are operational limits. For example, the
|
||||
number of gigabytes allowed for each tenant can be controlled so that
|
||||
cloud resources are optimized. Quotas can be enforced at both the tenant
|
||||
(or project) and the tenant-user level.
|
||||
|
||||
Typically, you change quotas when a project needs more than ten
|
||||
volumes or 1 |nbsp| TB on a compute node.
|
||||
|
||||
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`).
|
||||
Additionally, you can update Compute service quotas for
|
||||
tenant users.
|
||||
|
||||
The following table describes the Compute and Block Storage service quotas:
|
||||
|
||||
.. _compute_quotas:
|
||||
|
||||
**Quota Descriptions**
|
||||
|
||||
+--------------------+------------------------------------+---------------+
|
||||
| Quota Name | Defines the number of | Service |
|
||||
+====================+====================================+===============+
|
||||
| Gigabytes | Volume gigabytes allowed for | Block Storage |
|
||||
| | each project. | |
|
||||
+--------------------+------------------------------------+---------------+
|
||||
| Instances | Instances allowed for each | Compute |
|
||||
| | project. | |
|
||||
+--------------------+------------------------------------+---------------+
|
||||
| Injected Files | Injected files allowed for each | Compute |
|
||||
| | project. | |
|
||||
+--------------------+------------------------------------+---------------+
|
||||
| Injected File | Content bytes allowed for each | Compute |
|
||||
| Content Bytes | injected file. | |
|
||||
+--------------------+------------------------------------+---------------+
|
||||
| Keypairs | Number of keypairs. | Compute |
|
||||
+--------------------+------------------------------------+---------------+
|
||||
| Metadata Items | Metadata items allowed for each | Compute |
|
||||
| | instance. | |
|
||||
+--------------------+------------------------------------+---------------+
|
||||
| RAM (MB) | RAM megabytes allowed for | Compute |
|
||||
| | each instance. | |
|
||||
+--------------------+------------------------------------+---------------+
|
||||
| Security Groups | Security groups allowed for each | Compute |
|
||||
| | project. | |
|
||||
+--------------------+------------------------------------+---------------+
|
||||
| Security Group | Rules allowed for each security | Compute |
|
||||
| Rules | group. | |
|
||||
+--------------------+------------------------------------+---------------+
|
||||
| Snapshots | Volume snapshots allowed for | Block Storage |
|
||||
| | each project. | |
|
||||
+--------------------+------------------------------------+---------------+
|
||||
| VCPUs | Instance cores allowed for each | Compute |
|
||||
| | project. | |
|
||||
+--------------------+------------------------------------+---------------+
|
||||
| Volumes | Volumes allowed for each | Block Storage |
|
||||
| | project. | |
|
||||
+--------------------+------------------------------------+---------------+
|
||||
|
||||
.. _dashboard_view_quotas_procedure:
|
||||
|
||||
View default project quotas
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project
|
||||
from the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Defaults` category.
|
||||
|
||||
#. 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.
|
||||
|
||||
.. _dashboard_update_project_quotas:
|
||||
|
||||
Update project quotas
|
||||
~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project
|
||||
from the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, open the :guilabel:`System` tab
|
||||
and click the :guilabel:`Defaults` category.
|
||||
|
||||
#. Click the :guilabel:`Update Defaults` button.
|
||||
|
||||
#. In the :guilabel:`Update Default Quotas` window,
|
||||
you can edit the default quota values.
|
||||
|
||||
#. 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`.
|
|
@ -1,41 +0,0 @@
|
|||
===========================
|
||||
View cloud usage statistics
|
||||
===========================
|
||||
|
||||
The Telemetry service provides user-level usage data for
|
||||
OpenStack-based clouds, which can be used for customer billing, system
|
||||
monitoring, or alerts. Data can be collected by notifications sent by
|
||||
existing OpenStack components (for example, usage events emitted from
|
||||
Compute) or by polling the infrastructure (for example, libvirt).
|
||||
|
||||
.. note::
|
||||
|
||||
You can only view metering statistics on the dashboard (available
|
||||
only to administrators).
|
||||
The Telemetry service must be set up and administered through the
|
||||
:command:`ceilometer` command-line interface (CLI).
|
||||
|
||||
For basic administration information, refer to the "Measure Cloud
|
||||
Resources" chapter in the `OpenStack End User Guide
|
||||
<http://docs.openstack.org/user-guide/>`_.
|
||||
|
||||
.. _dashboard-view-resource-stats:
|
||||
|
||||
View resource statistics
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Log in to the dashboard and select the :guilabel:`admin` project
|
||||
from the drop-down list.
|
||||
|
||||
#. On the :guilabel:`Admin` tab, click the :guilabel:`Resource Usage` category.
|
||||
|
||||
#. Click the:
|
||||
|
||||
* :guilabel:`Usage Report` tab to view a usage report per tenant (project)
|
||||
by specifying the time period (or even use a calendar to define
|
||||
a date range).
|
||||
|
||||
* :guilabel:`Stats` tab to view a multi-series line chart with
|
||||
user-defined meters. You group by project, define the value type
|
||||
(min, max, avg, or sum), and specify the time period (or even use
|
||||
a calendar to define a date range).
|
Binary file not shown.
Before Width: | Height: | Size: 96 KiB |
Binary file not shown.
Before Width: | Height: | Size: 50 KiB |
Binary file not shown.
Before Width: | Height: | Size: 37 KiB |
Binary file not shown.
Before Width: | Height: | Size: 85 KiB |
|
@ -1,35 +0,0 @@
|
|||
==========================
|
||||
OpenStack Admin User Guide
|
||||
==========================
|
||||
|
||||
Abstract
|
||||
~~~~~~~~
|
||||
|
||||
OpenStack is an open source cloud computing platform for public and
|
||||
private clouds. A series of interrelated projects deliver a cloud
|
||||
infrastructure solution. This guide shows OpenStack admin users how to
|
||||
create and manage resources in an OpenStack cloud with the OpenStack
|
||||
dashboard or OpenStack client commands.
|
||||
|
||||
This guide documents OpenStack Mitaka, OpenStack Liberty, and OpenStack Kilo
|
||||
releases.
|
||||
|
||||
Contents
|
||||
~~~~~~~~
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
common/conventions.rst
|
||||
intro-admin.rst
|
||||
dashboard.rst
|
||||
cli.rst
|
||||
|
||||
common/app_support.rst
|
||||
|
||||
common/glossary.rst
|
||||
|
||||
Search in this guide
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* :ref:`search`
|
|
@ -1,41 +0,0 @@
|
|||
========================================
|
||||
How can I administer an OpenStack cloud?
|
||||
========================================
|
||||
|
||||
As an OpenStack cloud administrative user, you can manage tenants,
|
||||
known as projects, users, services, images, flavors, and quotas.
|
||||
|
||||
The examples in this guide show you how to perform tasks by using the
|
||||
following methods:
|
||||
|
||||
* OpenStack dashboard. Use this web-based graphical interface, code
|
||||
named `horizon <https://git.openstack.org/cgit/openstack/horizon>`__,
|
||||
to view, create, and manage resources and services.
|
||||
|
||||
* OpenStack command-line clients. Each core OpenStack project has a
|
||||
command-line client that you can use to run simple commands to view,
|
||||
create, and manage resources and services in a cloud and automate
|
||||
tasks by using scripts.
|
||||
|
||||
You can modify these examples for your specific use cases.
|
||||
|
||||
In addition to these ways of interacting with a cloud, you can access
|
||||
the OpenStack APIs directly or indirectly through `cURL <http://curl.haxx.se>`__ commands or
|
||||
open SDKs. You can automate access or build tools to manage resources
|
||||
and services by using the native OpenStack APIs or the EC2
|
||||
compatibility API.
|
||||
|
||||
To use the OpenStack APIs, it helps to be familiar with HTTP/1.1,
|
||||
RESTful web services, the OpenStack services, and JSON or XML data
|
||||
serialization formats.
|
||||
|
||||
Who should read this book?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This book is written for administrators who maintain and secure an
|
||||
OpenStack cloud installation to serve end users' needs. You should
|
||||
have years of experience with Linux-based tools for system
|
||||
administration. You should also be familiar with OpenStack basics,
|
||||
such as managing projects and users, troubleshooting, performing
|
||||
backup and recovery, and monitoring. For more information, see the
|
||||
`OpenStack Operations Guide <http://docs.openstack.org/ops>`__.
|
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
@ -1,350 +0,0 @@
|
|||
=================================
|
||||
Manage projects, users, and roles
|
||||
=================================
|
||||
As a cloud administrator, you manage projects, users, and
|
||||
roles. Projects are organizational units in the cloud to which
|
||||
you can assign users. Projects are also known as ``tenants`` or
|
||||
``accounts``. Users can be members of one or more projects. Roles
|
||||
define which actions users can perform. You assign roles to
|
||||
user-project pairs.
|
||||
|
||||
You can define actions for OpenStack service roles in the
|
||||
``/etc/PROJECT/policy.json`` files. For example, define actions for
|
||||
Compute service roles in the ``/etc/nova/policy.json`` file.
|
||||
|
||||
You can manage projects, users, and roles independently from each other.
|
||||
|
||||
During cloud set up, the operator defines at least one project, user,
|
||||
and role.
|
||||
|
||||
Learn how to add, update, and delete projects and users, assign users to
|
||||
one or more projects, and change or remove the assignment. To enable or
|
||||
temporarily disable a project or user, you update that project or user.
|
||||
You can also change quotas at the project level.
|
||||
|
||||
Before you can delete a user account, you must remove the user account
|
||||
from its primary project.
|
||||
|
||||
Before you can run client commands, you must download and
|
||||
source an OpenStack RC file. See `Download and source the OpenStack RC file
|
||||
<http://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html#download-and-source-the-openstack-rc-file>`_.
|
||||
|
||||
Projects
|
||||
~~~~~~~~
|
||||
|
||||
A project is a group of zero or more users. In Compute, a project owns
|
||||
virtual machines. In Object Storage, a project owns containers. Users
|
||||
can be associated with more than one project. Each project and user
|
||||
pairing can have a role associated with it.
|
||||
|
||||
List projects
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
List all projects with their ID, name, and whether they are
|
||||
enabled or disabled:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack project list
|
||||
+----------------------------------+--------------------+
|
||||
| id | name |
|
||||
+----------------------------------+--------------------+
|
||||
| f7ac731cc11f40efbc03a9f9e1d1d21f | admin |
|
||||
| c150ab41f0d9443f8874e32e725a4cc8 | alt_demo |
|
||||
| a9debfe41a6d4d09a677da737b907d5e | demo |
|
||||
| 9208739195a34c628c58c95d157917d7 | invisible_to_admin |
|
||||
| 3943a53dc92a49b2827fae94363851e1 | service |
|
||||
| 80cab5e1f02045abad92a2864cfd76cb | test_project |
|
||||
+----------------------------------+--------------------+
|
||||
|
||||
Create a project
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Create a project named ``new-project``:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack project create --description 'my new project' new-project
|
||||
+-------------+----------------------------------+
|
||||
| Field | Value |
|
||||
+-------------+----------------------------------+
|
||||
| description | my new project |
|
||||
| enabled | True |
|
||||
| id | 1a4a0618b306462c9830f876b0bd6af2 |
|
||||
| name | new-project |
|
||||
+-------------+----------------------------------+
|
||||
|
||||
Update a project
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Specify the project ID to update a project. You can update the name,
|
||||
description, and enabled status of a project.
|
||||
|
||||
- To temporarily disable a project:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack project set PROJECT_ID --disable
|
||||
|
||||
- To enable a disabled project:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack project set PROJECT_ID --enable
|
||||
|
||||
- To update the name of a project:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack project set PROJECT_ID --name project-new
|
||||
|
||||
- To verify your changes, show information for the updated project:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ 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-block:: console
|
||||
|
||||
$ openstack project delete PROJECT_ID
|
||||
|
||||
User
|
||||
~~~~
|
||||
|
||||
List users
|
||||
^^^^^^^^^^
|
||||
|
||||
List all users:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack user list
|
||||
+----------------------------------+----------+
|
||||
| id | name |
|
||||
+----------------------------------+----------+
|
||||
| 352b37f5c89144d4ad0534139266d51f | admin |
|
||||
| 86c0de739bcb4802b8dc786921355813 | demo |
|
||||
| 32ec34aae8ea432e8af560a1cec0e881 | glance |
|
||||
| 7047fcb7908e420cb36e13bbd72c972c | nova |
|
||||
+----------------------------------+----------+
|
||||
|
||||
Create a user
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
To create a user, you must specify a name. Optionally, you can
|
||||
specify a tenant ID, password, and email address. It is recommended
|
||||
that you include the tenant ID and password because the user cannot
|
||||
log in to the dashboard without this information.
|
||||
|
||||
Create the ``new-user`` user:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack user create --project new-project --password PASSWORD new-user
|
||||
+----------+----------------------------------+
|
||||
| Field | Value |
|
||||
+----------+----------------------------------+
|
||||
| email | |
|
||||
| enabled | True |
|
||||
| id | 6e5140962b424cb9814fb172889d3be2 |
|
||||
| name | new-user |
|
||||
| tenantId | new-project |
|
||||
+----------+----------------------------------+
|
||||
|
||||
Update a user
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
You can update the name, email address, and enabled status for a user.
|
||||
|
||||
- To temporarily disable a user account:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ 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
|
||||
can enable the user at any time.
|
||||
|
||||
- To enable a disabled user account:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack user set USER_NAME --enable
|
||||
|
||||
- To change the name and description for a user account:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ 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-block:: console
|
||||
|
||||
$ openstack user delete USER_NAME
|
||||
|
||||
Roles and role assignments
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
List available roles
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
List the available roles:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack role list
|
||||
+----------------------------------+---------------+
|
||||
| id | name |
|
||||
+----------------------------------+---------------+
|
||||
| 71ccc37d41c8491c975ae72676db687f | Member |
|
||||
| 149f50a1fe684bfa88dae76a48d26ef7 | ResellerAdmin |
|
||||
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_ |
|
||||
| 6ecf391421604da985db2f141e46a7c8 | admin |
|
||||
| deb4fffd123c4d02a907c2c74559dccf | anotherrole |
|
||||
+----------------------------------+---------------+
|
||||
|
||||
Create a role
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
Users can be members of multiple projects. To assign users to multiple
|
||||
projects, define a role and assign that role to a user-project pair.
|
||||
|
||||
Create the ``new-role`` role:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack role create new-role
|
||||
+--------+----------------------------------+
|
||||
| Field | Value |
|
||||
+--------+----------------------------------+
|
||||
| id | bef1f95537914b1295da6aa038ef4de6 |
|
||||
| name | new-role |
|
||||
+--------+----------------------------------+
|
||||
|
||||
Assign a role
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
To assign a user to a project, you must assign the role to a
|
||||
user-project pair. To do this, you need the user, role, and project
|
||||
IDs.
|
||||
|
||||
#. List users and note the user ID you want to assign to the role:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack user list
|
||||
+----------------------------------+----------+---------+----------------------+
|
||||
| id | name | enabled | email |
|
||||
+----------------------------------+----------+---------+----------------------+
|
||||
| 352b37f5c89144d4ad0534139266d51f | admin | True | admin@example.com |
|
||||
| 981422ec906d4842b2fc2a8658a5b534 | alt_demo | True | alt_demo@example.com |
|
||||
| 036e22a764ae497992f5fb8e9fd79896 | cinder | True | cinder@example.com |
|
||||
| 86c0de739bcb4802b8dc786921355813 | demo | True | demo@example.com |
|
||||
| 32ec34aae8ea432e8af560a1cec0e881 | glance | True | glance@example.com |
|
||||
| 7047fcb7908e420cb36e13bbd72c972c | nova | True | nova@example.com |
|
||||
+----------------------------------+----------+---------+----------------------+
|
||||
|
||||
#. List role IDs and note the role ID you want to assign:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack role list
|
||||
+----------------------------------+---------------+
|
||||
| id | name |
|
||||
+----------------------------------+---------------+
|
||||
| 71ccc37d41c8491c975ae72676db687f | Member |
|
||||
| 149f50a1fe684bfa88dae76a48d26ef7 | ResellerAdmin |
|
||||
| 9fe2ff9ee4384b1894a90878d3e92bab | _member_ |
|
||||
| 6ecf391421604da985db2f141e46a7c8 | admin |
|
||||
| deb4fffd123c4d02a907c2c74559dccf | anotherrole |
|
||||
| bef1f95537914b1295da6aa038ef4de6 | new-role |
|
||||
+----------------------------------+---------------+
|
||||
|
||||
#. List projects and note the project ID you want to assign to the role:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack project list
|
||||
+----------------------------------+--------------------+---------+
|
||||
| id | name | enabled |
|
||||
+----------------------------------+--------------------+---------+
|
||||
| f7ac731cc11f40efbc03a9f9e1d1d21f | admin | True |
|
||||
| c150ab41f0d9443f8874e32e725a4cc8 | alt_demo | True |
|
||||
| a9debfe41a6d4d09a677da737b907d5e | demo | True |
|
||||
| 9208739195a34c628c58c95d157917d7 | invisible_to_admin | True |
|
||||
| caa9b4ce7d5c4225aa25d6ff8b35c31f | new-user | True |
|
||||
| 1a4a0618b306462c9830f876b0bd6af2 | project-new | True |
|
||||
| 3943a53dc92a49b2827fae94363851e1 | service | True |
|
||||
| 80cab5e1f02045abad92a2864cfd76cb | test_project | True |
|
||||
+----------------------------------+--------------------+---------+
|
||||
|
||||
#. Assign a role to a user-project pair. In this example, assign the
|
||||
``new-role`` role to the ``demo`` and ``test-project`` pair:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack role add --user USER_NAME --project TENANT_ID ROLE_NAME
|
||||
|
||||
#. Verify the role assignment:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack role list --user USER_NAME --project TENANT_ID
|
||||
+--------------+----------+---------------------------+--------------+
|
||||
| id | name | user_id | tenant_id |
|
||||
+--------------+----------+---------------------------+--------------+
|
||||
| bef1f9553... | new-role | 86c0de739bcb4802b21355... | 80cab5e1f... |
|
||||
+--------------+----------+---------------------------+--------------+
|
||||
|
||||
View role details
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
View details for a specified role:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack role show ROLE_NAME
|
||||
+----------+----------------------------------+
|
||||
| Field | Value |
|
||||
+----------+----------------------------------+
|
||||
| id | bef1f95537914b1295da6aa038ef4de6 |
|
||||
| name | new-role |
|
||||
+----------+----------------------------------+
|
||||
|
||||
Remove a role
|
||||
^^^^^^^^^^^^^
|
||||
|
||||
Remove a role from a user-project pair:
|
||||
|
||||
#. Run the :command:`openstack role remove` command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack role remove --user USER_NAME --project TENANT_ID ROLE_NAME
|
||||
|
||||
#. Verify the role removal:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ openstack role list --user USER_NAME --project TENANT_ID
|
||||
|
||||
If the role was removed, the command output omits the removed role.
|
|
@ -1,316 +0,0 @@
|
|||
================================
|
||||
Manage Networking service quotas
|
||||
================================
|
||||
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-block:: ini
|
||||
|
||||
$ neutron net-create test_net
|
||||
Quota exceeded for resources: ['network']
|
||||
|
||||
Per-tenant quota configuration is also supported by the quota
|
||||
extension API. See :ref:`cfg_quotas_per_tenant` for details.
|
||||
|
||||
Basic quota configuration
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
In the Networking default quota mechanism, all tenants have
|
||||
the same quota values, such as the number of resources that a
|
||||
tenant can create.
|
||||
|
||||
The quota value is defined in the OpenStack Networking
|
||||
``neutron.conf`` configuration file. To disable quotas for
|
||||
a specific resource, such as network, subnet,
|
||||
or port, remove a corresponding item from ``quota_items``.
|
||||
This example shows the default quota values:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[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 subnets allowed per tenant, and minus means unlimited
|
||||
quota_subnet = 10
|
||||
|
||||
# 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
|
||||
|
||||
OpenStack Networking also supports quotas for L3 resources:
|
||||
router and floating IP. Add these lines to the
|
||||
``quotas`` section in the ``neutron.conf`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[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
|
||||
|
||||
.. note::
|
||||
|
||||
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 tenant. Add these lines to the
|
||||
``quotas`` section in the ``neutron.conf`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[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
|
||||
|
||||
.. note::
|
||||
|
||||
The ``quota_items`` option does not affect these quotas.
|
||||
|
||||
.. _cfg_quotas_per_tenant:
|
||||
|
||||
Configure per-tenant quotas
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
OpenStack Networking also supports per-tenant quota limit by
|
||||
quota extension API.
|
||||
|
||||
Use these commands to manage per-tenant quotas:
|
||||
|
||||
neutron quota-delete
|
||||
Delete defined quotas for a specified tenant
|
||||
|
||||
neutron quota-list
|
||||
Lists defined quotas for all tenants
|
||||
|
||||
neutron quota-show
|
||||
Shows quotas for a specified tenant
|
||||
|
||||
neutron quota-update
|
||||
Updates quotas for a specified tenant
|
||||
|
||||
Only users with the ``admin`` role can change a quota value. By default,
|
||||
the default set of quotas are enforced for all tenants, so no
|
||||
:command:`quota-create` command exists.
|
||||
|
||||
#. Configure Networking to show per-tenant quotas
|
||||
|
||||
Set the ``quota_driver`` option in the ``neutron.conf`` file.
|
||||
|
||||
.. 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:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ neutron ext-list -c alias -c name
|
||||
|
||||
The command shows the ``quotas`` extension, which provides
|
||||
per-tenant quota management support.
|
||||
|
||||
.. 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:
|
||||
|
||||
.. 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::
|
||||
|
||||
Only some plug-ins support per-tenant quotas.
|
||||
Specifically, Open vSwitch, Linux Bridge, and VMware NSX
|
||||
support them, but new versions of other plug-ins might
|
||||
bring additional functionality. See the documentation for
|
||||
each plug-in.
|
||||
|
||||
#. List tenants who have per-tenant quota support.
|
||||
|
||||
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:
|
||||
|
||||
.. 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
|
||||
:option:`--tenant_id` parameter. If per-tenant quota limits are
|
||||
not enabled for the tenant, the command shows the default
|
||||
set of quotas.
|
||||
|
||||
.. 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.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ neutron quota-show
|
||||
+------------+-------+
|
||||
| Field | Value |
|
||||
+------------+-------+
|
||||
| floatingip | 20 |
|
||||
| network | 5 |
|
||||
| port | 20 |
|
||||
| router | 10 |
|
||||
| subnet | 5 |
|
||||
+------------+-------+
|
||||
|
||||
#. Update quota values for a specified tenant.
|
||||
|
||||
Use the :command:`quota-update` command to
|
||||
update a quota for a specified tenant.
|
||||
|
||||
.. 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.
|
||||
|
||||
.. 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.
|
||||
For example, update the limit of the number of floating
|
||||
IPs for the specified tenant:
|
||||
|
||||
.. 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 resources through one
|
||||
command:
|
||||
|
||||
.. 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.
|
||||
|
||||
.. 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.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ neutron quota-show --tenant_id 6f88036c45344d9999a1f971e4882723
|
||||
+------------+-------+
|
||||
| Field | Value |
|
||||
+------------+-------+
|
||||
| floatingip | 50 |
|
||||
| network | 10 |
|
||||
| port | 50 |
|
||||
| router | 10 |
|
||||
| subnet | 10 |
|
||||
+------------+-------+
|
|
@ -1,205 +0,0 @@
|
|||
=======================
|
||||
Manage project security
|
||||
=======================
|
||||
|
||||
Security groups are sets of IP filter rules that are applied to all
|
||||
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
|
||||
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
|
||||
``/etc/nova/nova.conf`` file to globally control whether the rules apply
|
||||
to hosts which share a network.
|
||||
|
||||
If set to:
|
||||
|
||||
- ``True`` (default), hosts on the same subnet are not filtered and are
|
||||
allowed to pass all types of traffic between them. On a flat network,
|
||||
this allows all instances from all projects unfiltered communication.
|
||||
With VLAN networking, this allows access between instances within the
|
||||
same project. You can also simulate this setting by configuring the
|
||||
default security group to allow all traffic from the subnet.
|
||||
|
||||
- ``False``, security groups are enforced for all connections.
|
||||
|
||||
Additionally, the number of maximum rules per security group is
|
||||
controlled by the ``security_group_rules`` and the number of allowed
|
||||
security groups per project is controlled by the ``security_groups``
|
||||
quota (see the `Manage quotas <http://docs.openstack.org/user-guide-admin/cli_set_quotas.html>`_
|
||||
section).
|
||||
|
||||
List and view current security groups
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
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 example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
export OS_USERNAME=demo00
|
||||
export OS_TENANT_NAME=tenant01
|
||||
|
||||
#. Output security groups, as follows:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova secgroup-list
|
||||
+---------+-------------+
|
||||
| Name | Description |
|
||||
+---------+-------------+
|
||||
| default | default |
|
||||
| open | all ports |
|
||||
+---------+-------------+
|
||||
|
||||
#. View the details of a group, as follows:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova secgroup-list-rules groupName
|
||||
|
||||
For example:
|
||||
|
||||
.. 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 | |
|
||||
+-------------+-----------+---------+-----------+--------------+
|
||||
|
||||
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
|
||||
third columns specify the affected port range. The third column
|
||||
specifies the IP range in CIDR format. This example shows the full
|
||||
port range for all protocols allowed from all IPs.
|
||||
|
||||
Create a security group
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
When adding a new security group, you should pick a descriptive but
|
||||
brief name. This name shows up in brief descriptions of the instances
|
||||
that use it where the longer description field often does not. For
|
||||
example, seeing that an instance is using security group "http" is much
|
||||
easier to understand than "bobs\_group" or "secgrp1".
|
||||
|
||||
#. Ensure your system variables are set for the user and tenant for
|
||||
which you are creating security group rules.
|
||||
|
||||
#. Add the new security group, as follows:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova secgroup-create GroupName Description
|
||||
|
||||
For example:
|
||||
|
||||
.. 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. |
|
||||
+--------------------------------------+-------------+----------------------------------------------+
|
||||
|
||||
#. Add a new group rule, as follows:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova secgroup-add-rule secGroupName ip-protocol from-port to-port CIDR
|
||||
|
||||
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-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 | |
|
||||
+-------------+-----------+---------+-----------+--------------+
|
||||
|
||||
You can create complex rule sets by creating additional rules. For
|
||||
example, if you want to pass both HTTP and HTTPS traffic, run:
|
||||
|
||||
.. 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 | |
|
||||
+-------------+-----------+---------+-----------+--------------+
|
||||
|
||||
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-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 | |
|
||||
+-------------+-----------+---------+-----------+--------------+
|
||||
|
||||
Delete a security group
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
#. Ensure your system variables are set for the user and tenant for
|
||||
which you are deleting a security group.
|
||||
|
||||
#. Delete the new security group, as follows:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova secgroup-delete GroupName
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ 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 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.
|
||||
|
||||
#. Make sure to set the system variables for the user and tenant for
|
||||
which you are creating a security group rule.
|
||||
|
||||
#. Add a source group, as follows:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ nova secgroup-add-group-rule secGroupName source-group ip-protocol from-port to-port
|
||||
|
||||
For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ 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.
|
|
@ -47,6 +47,10 @@ User Guides
|
|||
* Troubleshooting chapters now have consistent formatting, which is
|
||||
a step toward improved troubleshooting sections.
|
||||
|
||||
* The **Admin User Guide** content has been removed from
|
||||
OpenStack.org/docs since all files have been reorganised into
|
||||
the **Administrator guide**.
|
||||
|
||||
Virtual Machine Image Guide
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
|
Loading…
Reference in New Issue