openstack
/
openstack-manuals
Code Issues Proposed changes

[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
changes/88/302088/3
Joseph Robinson 2016-04-06 18:14:26 +10:00 committed by KATO Tomoyuki
parent 12994d33ba
commit fa7cadabde
48 changed files with 5 additions and 11340 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc-tools-check-languages.conf
View File

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

30
doc/user-guide-admin/setup.cfg
View File

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

30
doc/user-guide-admin/setup.py
View File

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

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

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

22
doc/user-guide-admin/source/cli.rst
View File

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

16
doc/user-guide-admin/source/cli_admin_manage_environment.rst
View File

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

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

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

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

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

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

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

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

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

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

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

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

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

9
doc/user-guide-admin/source/cli_manage_services.rst
View File

@ -1,9 +0,0 @@
===============
Manage services
===============
.. toctree::
:maxdepth: 2
cli_keystone_manage_services.rst
cli_nova_manage_services.rst

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@ -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
doc/user-guide-admin/source/common
View File

@ -1 +0,0 @@
../../common

307
doc/user-guide-admin/source/conf.py
View File

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