openstack/openstack-ansible
Code Issues Proposed changes

Merge "Various Documentation Updates"

Browse Source
This commit is contained in:
Jenkins 2015-10-05 20:10:41 +00:00 committed by Gerrit Code Review
commit c18c667459
83 changed files with 588 additions and 691 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

102
CONTRIBUTING.rst
View File

@ -1,102 +0,0 @@
OpenStack Ansible Deployment
############################
:tags: openstack, cloud, ansible
:category: \*nix
contributor guidelines
^^^^^^^^^^^^^^^^^^^^^^
Bugs
----
Bugs should be filed on Launchpad at "https://bugs.launchpad.net/openstack-ansible".
When submitting a bug, or working on a bug, please ensure the following criteria are met:
* The description clearly states or describes the original problem or root cause of the problem.
* Include historical information on how the problem was identified.
* Any relevant logs are included.
* If the issue is a bug that needs fixing in a branch other than master, please note the associated branch within the launchpad issue.
* The provided information should be totally self-contained. External access to web services/sites should not be needed.
* Steps to reproduce the problem if possible.
Tags:
If it's a bug that needs fixing in a branch in addition to master, add a '\<release\>-backport-potential' tag (e.g. ``juno-backport-potential``). There are predefined tags that will auto-complete.
Status:
Please leave the **status** of an issue alone until someone confirms it or a member of the bugs team triages it. While waiting for the issue to be confirmed or triaged the status should remain as **New**.
Importance:
Should only be touched if it is a Blocker/Gating issue. If it is, please set to **High**, and only use **Critical** if you have found a bug that can take down whole infrastructures. Once the importance has been changed the status should be changed to *Triaged* by someone other than the bug creator.
Triaging bugs:
Reported bugs need prioritization, confirmation, and shouldn't go stale. If you care about OpenStack stability but aren't wanting to actively develop the roles and playbooks used within the "openstack-ansible" project consider contributing in the area of bug triage, which helps immensely. The whole process is described in the upstream `Bug Triage Documentation`_.
Submitting Code
---------------
* Write good commit messages. We follow the OpenStack "`Git Commit Good Practice`_" guide. if you have any questions regarding how to write good commit messages please review the upstream OpenStack documentation.
* Changes to the project should be submitted for review via the Gerrit tool, following the `workflow documented here`_.
* Pull requests submitted through GitHub will be ignored and closed without regard.
* All feature additions/deletions should be accompanied by a blueprint/spec. IE: adding additional active agents to neutron, developing a new service role, etc...
* Before creating blueprint/spec an associated issue should be raised on launchpad. This issue will be triaged and a determination will be made on how large the change is and whether or not the change warrants a blueprint/spec. Both features and bug fixes may require the creation of a blueprint/spec. This requirement will be voted on by core reviewers and will be based on the size and impact of the change.
* All blueprints/specs should be voted on and approved by core reviewers before any associated code will be merged. For more information on blueprints/specs please review the `upstream OpenStack Blueprint documentation`_. At the time the blueprint/spec is voted on a determination will be made whether or not the work will be backported to any of the "released" branches.
* Patches should be focused on solving one problem at a time. If the review is overly complex or generally large the initial commit will receive a "**-2**" and the contributor will be asked to split the patch up across multiple reviews. In the case of complex feature additions the design and implementation of the feature should be done in such a way that it can be submitted in multiple patches using dependencies. Using dependent changes should always aim to result in a working build throughout the dependency chain. More information on `advanced gerrit usage and dependent changes can be found here`_.
* All patch sets should adhere to the Ansible Style Guide listed here as well as adhere to the Ansible best practices when possible. `Ansible best practices can be found here`_.
* All changes should be clearly listed in the commit message, with an associated bug id/blueprint along with any extra information where applicable.
* Refactoring work should never include additional "rider" features. Features that may pertain to something that was re-factored should be raised as an issue and submitted in prior or subsequent patches.
Backporting
-----------
* Backporting is defined as the act of reproducing a change from another branch. Unclean/squashed/modified cherry-picks and complete reimplementations are OK.
* Backporting is often done by using the same code (via cherry picking), but this is not always the case. This method is preferred when the cherry-pick provides a complete solution for the targeted problem.
* When cherry-picking a commit from one branch to another the commit message should be amended with any files that may have been in conflict while performing the cherry-pick operation. Additionally, cherry-pick commit messages should contain the original commit *SHA* near the bottom of the new commit message. This can be done with ``cherry-pick -x``. Here's more information on `Submitting a change to a branch for review`_.
* Every backport commit must still only solve one problem, as per the guidelines in `Submitting Code`_.
* If a backport is a squashed set of cherry-picked commits, the original SHAs should be referenced in the commit message and the reason for squashing the commits should be clearly explained.
* When a cherry-pick is modified in any way, the changes made and the reasons for them must be explicitly expressed in the commit message.
* Refactoring work must not be backported to a "released" branch.
Style Guide
-----------
When creating tasks and other roles for use in Ansible please create then using the YAML dictionary format.
Example YAML dictionary format:
.. code-block:: yaml
- name: The name of the tasks
module_name:
thing1: "some-stuff"
thing2: "some-other-stuff"
tags:
- some-tag
- some-other-tag
Example what **NOT** to do:
.. code-block:: yaml
- name: The name of the tasks
module_name: thing1="some-stuff" thing2="some-other-stuff"
tags: some-tag
.. code-block:: yaml
- name: The name of the tasks
module_name: >
thing1="some-stuff"
thing2="some-other-stuff"
tags: some-tag
Usage of the ">" and "|" operators should be limited to Ansible conditionals and command modules such as the Ansible ``shell`` or ``command``.
.. _Git Commit Good Practice: https://wiki.openstack.org/wiki/GitCommitMessages
.. _workflow documented here: http://docs.openstack.org/infra/manual/developers.html#development-workflow
.. _upstream OpenStack Blueprint documentation: https://wiki.openstack.org/wiki/Blueprints
.. _advanced gerrit usage and dependent changes can be found here: http://www.mediawiki.org/wiki/Gerrit/Advanced_usage
.. _Ansible best practices can be found here: http://docs.ansible.com/playbooks_best_practices.html
.. _Submitting a change to a branch for review: http://www.mediawiki.org/wiki/Gerrit/Advanced_usage#Submitting_a_change_to_a_branch_for_review_.28.22backporting.22.29
.. _Bug Triage Documentation: https://wiki.openstack.org/wiki/BugTriage

83
README.rst
View File

@ -1,65 +1,32 @@
OpenStack Ansible Deployment
############################
:date: 2015-02-02 22:00
:tags: lxc, openstack, cloud, ansible
:category: \*nix
OpenStack Ansible
#################
OpenStack-Ansible is an `official OpenStack project`_ which aims to deploy
production environments from source in a way that makes it scalable while
also being simple to operate, upgrade, and grow.
Playbooks
---------
For an overview of the mission, repositories and related Wiki home page,
please see the formal `Home Page`_ for the project.
There are several playbooks within that will setup hosts for use in OpenStack Cloud. The playbooks will enable LXC on hosts and provides the ability to deploy LXC containers for use within openstack.
For those looking to test OpenStack-Ansible using an All-In-One (AIO) build,
please see the `Quick Start`_ guide.
Plays:
* ``setup-hosts.yml`` Performs host setup for use with LXC in the OpenStack hosts.
* ``setup-infrastructure.yml`` Performs all of the setup for all infrastructure components.
* ``setup-openstack.yml`` Performs all of the setup for all of the OpenStack components.
For more detailed Installation and Operator documentation, please see the
`Install Guide`_.
* If you dont want to run plays individually you can simply run ``setup-everything.yml`` which will perform all of the setup and installation for you.
If OpenStack-Ansible is missing something you'd like to see included, then
we encourage you to see the `Developer Documentation` for more details on
how you can get involved.
Basic Setup:
1. If you have any roles that you'd like to have pulled in that are outside the scope and or replace modules within this repository please add them to the ``ansible-role-requirements.yml`` file. In this file you will want to fill in the details for the role you want to pull in using standard ansible galaxy format.
If you have some questions, or would like some assistance with achieving your
goals, then please feel free to reach out to us on the
`OpenStack Mailing Lists`_ (particularly openstack-operators or openstack-dev)
or on IRC in ``#openstack-ansible`` on the `freenode network`_.
.. code-block:: yaml
- name: SuperAwesomeModule
src: https://github.com/super-user/SuperAwesomeModule
version: master
2. Run the ``./scripts/bootstrap-ansible.sh`` script, which will install, pip, ansible 1.9.x, all of the required python packages, and bring in any third party ansible roles that you may want to add to the deployment.
3. Copy the ``etc/openstack_deploy`` directory to ``/etc/openstack_deploy``.
4. Fill in your ``openstack_deploy/openstack_user_config.yml``, ``openstack_deploy/user_secrets.yml`` and ``openstack_deploy/user_variables.yml`` files which you've just copied to your ``/etc/`` directory.
5. Generate all of your random passwords executing ``scripts/pw-token-gen.py --file /etc/openstack_deploy/user_secrets.yml``.
6. Accomplish all of the host networking that you want to use within the deployment. See the ``etc/network`` directory in this repository for an example network setup.
7. When ready change to the ``playbooks/`` directory and execute your desired plays. IE:
.. code-block:: bash
openstack-ansible setup-everything.yml
Notes
-----
* If you run the ``./scripts/bootstrap-ansible.sh`` script a wrapper script will be added to your system that wraps the ansible-playbook command to simplify the arguments required to run openstack ansible plays. The name of the wrapper script is **openstack-ansible**.
* The lxc network is created within the *lxcbr0* interface. This supports both NAT networks as well as more traditional networking. If NAT is enabled (default) the IPtables rules will be created along with the interface as a post-up processes. If you ever need to recreate the rules and or restart the dnsmask process you can bounce the interface IE: ``ifdown lxcb0; ifup lxcbr0`` or you can use the ``lxc-system-manage`` command.
* The tool ``lxc-system-manage`` is available on all lxc hosts and can assist in recreating parts of the LXC system whenever its needed.
* Inventory is generated by executing the ``playbooks/inventory/dynamic_inventory.py`` script. This is configured in the ``playbooks/ansible.cfg`` file.
* If you don't use the pw-token-gen.py script you will want to ensure the permissions on /etc/openstack_deploy/user_secrets.yml are more secure. ``chmod 0600 /etc/openstack_deploy/user_secrets.yml``
* Finding slow Ansible tasks is easier with the ``profile_tasks`` callback plugin. Review the notes in ``playbooks/plugins/callbacks/profile_tasks.py`` to enable it.
Bugs and Blueprints
-------------------
Everything we do is in launchpad and gerrit. If you'd like to raise a bug, feature request, or are looking for ways to contribute please go to "https://launchpad.net/openstack-ansible".
Documentation
-------------
To build the docs make sure that you have installed the python requirements as found within the ``dev-requirements.txt`` file and then run the following command from within the ``doc`` directory.
.. code-block:: bash
make html
.. _official OpenStack project: http://governance.openstack.org/reference/projects/index.html
.. _Home Page: http://governance.openstack.org/reference/projects/openstackansible.html
.. _Install Guide: http://docs.openstack.org/developer/openstack-ansible/install-guide/index.html
.. _Quick Start: http://docs.openstack.org/developer/openstack-ansible/developer-docs/quickstart-aio.html
.. _Developer Documentation: http://docs.openstack.org/developer/openstack-ansible/developer-docs/index.html
.. _OpenStack Mailing Lists: http://lists.openstack.org/
.. _freenode network: https://freenode.net/

236
development-stack.rst
View File

@ -1,236 +0,0 @@
OpenStack Ansible Deployment
############################
:date: 2015-02-02 22:00
:tags: lxc, openstack, cloud, ansible
:category: \*nix
Building a development stack
----------------------------
To deploy an *all-in-one* (AIO) environment for testing or contributing to
this project, use the scripts in the ``scripts`` directory. You must run these
scripts from the repository top-level directory. For example:
.. code-block:: console
$ git clone https://github.com/openstack/openstack-ansible \
/opt/openstack-ansible
$ cd /opt/openstack-ansible
$ scripts/bootstrap-aio.sh
Requirements
^^^^^^^^^^^^
* Quad-core processor capable of running KVM
* 8 GB of RAM
* 60 GB of storage
.. note::
By default, the deployment scripts use the file system on "/" for
containers. Optionally, the deployment scripts can use LVM for
containers. To use LVM, create the ``lvm`` volume group. Each
container uses a logical volume that requires **5 GB** of available
storage in the volume group.
If deploying on a Rackspace public cloud server, use the *general1-8* or
larger flavor. Optionally, you can use the Orchestration template
``osa-aio-heat-template.yml`` to launch a cloud server and deploy an AIO
environment on it.
These requirements may seem excessive; however, the default AIO deployment
builds a roughly 35-node environment that closely matches the reference
architecture. For example, components such as RabbitMQ, MariaDB with Galera,
source repository, and Identity service all use multiple containers to
simulate clustering.
Finally, the AIO deployment uses HAProxy for testing purposes only. Please
do not use this HAProxy configuration for production purposes because it
does not provide any redundancy.
.. note::
Never deploy an AIO environment on a host that you cannot risk breaking
or destroying.
Procedure
^^^^^^^^^
To deploy an AIO environment, complete these steps:
#. Clone the repository:
.. code-block:: console
$ git clone https://github.com/openstack/openstack-ansible \
/opt/openstack-ansible
#. Change to the repository top-level directory:
.. code-block:: console
$ cd /opt/openstack-ansible
#. By default, the repository uses the *master* branch. Optionally, you can
check out a different branch. For example, to check out the Kilo branch:
.. code-block:: console
$ git checkout kilo
#. By default, the scripts deploy all OpenStack services. Optionally, you can
disable one or more services using environment variables. See the
``DEPLOY_*`` variables in the ``run-playbooks.sh`` script for details. For
example, to disable the Telemetry service:
.. code-block:: console
$ export DEPLOY_CEILOMETER="no"
.. note::
The scripts still build containers for any service that you disable, but
do not deploy the service.
#. Prepare the host:
.. code-block:: console
$ scripts/bootstrap-aio.sh
.. note::
This script configures the host operating system and supplies values for
mandatory options in configuration files in the
``/etc/openstack_deploy`` directory.
#. Install the necessary Ansible components:
.. code-block:: console
$ scripts/bootstrap-ansible.sh
.. note::
Only run this script once.
#. Run the Ansible playbooks to deploy the environment:
.. code-block:: console
$ scripts/run-playbooks.sh
.. note::
You can run this script multiple times.
Optionally, you can run individual playbooks. For example, to deploy the
Identity service:
.. code-block:: console
$ cd /opt/openstack-ansible/playbooks
$ openstack-ansible os-keystone-install.yml
Rebuilding the stack
^^^^^^^^^^^^^^^^^^^^
Once you have completed your testing and or dev work if you'd like to tear down the stack and restart from a new build there is a play that will assist you in doing just that. Simply change to your playbooks directory and execute the ``lxc-containers-destroy.yml`` play.
Example:
.. code-block:: bash
# Move to the playbooks directory.
cd /opt/openstack-ansible/playbooks
# Destroy all of the running containers.
openstack-ansible lxc-containers-destroy.yml
# On the host stop all of the services that run locally and not within a container.
for i in $(ls /etc/init | grep -e nova -e swift -e neutron | awk -F'.' '{print $1}'); do service $i stop; done
# Uninstall the core services that were installed.
for i in $(pip freeze | grep -e nova -e neutron -e keystone -e swift); do pip uninstall -y $i; done
# Remove crusty directories.
rm -rf /openstack /etc/neutron /etc/nova /etc/swift /var/log/neutron /var/log/nova /var/log/swift
Using the teardown script:
The ``teardown.sh`` script that will destroy everything known within an environment. You should be aware that this script will destroy whole environments and should be used **WITH CAUTION**.
This script will destroy all of your running containers and remove items within the ``/openstack`` directory for the container. After the completion of this play you can rerun the ``run-playbooks.sh`` or you can run the plays manually to rebuild the stack.
Notice
^^^^^^
The system uses a number of variables. You should look a the scripts for a full explanation and description of all of the available variables that you can set. At a minimum you should be aware of the default public interface variable as you may be kicking on a box that does not have an ``eth0`` interface. To set the default public interface run the following.
.. code-block:: bash
export PUBLIC_INTERFACE="<<REPLACE WITH THE NAME OF THE INTERFACE>>" # This is only required if you dont have eth0
Diagram of stack
^^^^^^^^^^^^^^^^
Here is a basic diagram that attempts to illustrate what the AIO installation job is doing. **NOTICE** This diagram is not to scale and is not even 100% accurate, this diagram was built for informational purposes only and should **ONLY** be used as such.
Diagram::
====== ASCII Diagram for AIO infrastructure ======
------->[ ETH0 == Public Network ]
|
V [ * ] Socket Connections
[ HOST MACHINE ] [ <>v^ ] Network Connections
* ^ *
| | |-------------------------------------------------------
| | |
| |---------------->[ HAProxy ] |
| ^ |
| | |
| V |
| (BR-Interfaces)<------- |
| ^ * | |
*-[ LXC ]*--*----------------------|-----|------|----| |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | V * | |
| * | | [ Galera x3 ] |
| [ Memcached ]<------------| | | |
*-------*[ Rsyslog ]<--------------|--| | * |
| [ Repos Server x3 ]<------| ---|-->[ RabbitMQ x3 ] |
| [ Horizon x2 ]<-----------| | | |
| [ Nova api ec2 ]<---------|--| | |
| [ Nova api os ]<----------|->| | |
| [ Nova console ]<---------| | | |
| [ Nova Cert ]<------------|->| | |
| [ Ceilometer api ]<-------|->| | |
| [ Ceilometer collector ]<-|->| | |
| [ Cinder api ]<-----------|->| | |
| [ Glance api ]<-----------|->| | |
| [ Heat apis ]<------------|->| | [ Loop back devices ]*-*
| [ Heat engine ]<----------|->| | \ \ |
| ------>[ Nova api metadata ] | | | { LVM } { XFS x3 } |
| | [ Nova conductor ]<-------| | | * * |
| |----->[ Nova scheduler ]--------|->| | | | |
| | [ Keystone x3 ]<----------|->| | | | |
| | |--->[ Neutron agents ]*-------|--|---------------------------*
| | | [ Neutron server ]<-------|->| | | |
| | | |->[ Swift proxy ]<----------- | | | |
*-|-|-|-*[ Cinder volume ]*----------------------* | |
| | | | | | |
| | | ----------------------------------------- | |
| | ----------------------------------------- | | |
| | -------------------------| | | | |
| | | | | | |
| | V | | * |
---->[ Compute ]*[ Neutron linuxbridge ]<---| |->[ Swift storage ]-
====== ASCII Diagram for AIO infrastructure ======

171
doc/source/developer-docs/contribute.rst Normal file
View File

@ -0,0 +1,171 @@
`Home <index.html>`_ OpenStack-Ansible Developer Documentation
Contributor Guidelines
======================
Bugs
----
Bugs should be filed on `Bug Launchpad`_ for OpenStack-Ansible.
When submitting a bug, or working on a bug, please ensure the following
criteria are met:
* The description clearly states or describes the original problem or root
cause of the problem.
* Include historical information on how the problem was identified.
* Any relevant logs are included.
* If the issue is a bug that needs fixing in a branch other than master,
please note the associated branch within the launchpad issue.
* The provided information should be totally self-contained. External access
to web services/sites should not be needed.
* Steps to reproduce the problem if possible.
Tags
````
If it's a bug that needs fixing in a branch in addition to master, add a
'\<release\>-backport-potential' tag (e.g. ``kilo-backport-potential``).
There are predefined tags that will auto-complete.
Status
``````
Please leave the **status** of an issue alone until someone confirms it or
a member of the bugs team triages it. While waiting for the issue to be
confirmed or triaged the status should remain as **New**.
Importance
``````````
Should only be touched if it is a Blocker/Gating issue. If it is, please
set to **High**, and only use **Critical** if you have found a bug that
can take down whole infrastructures. Once the importance has been changed
the status should be changed to *Triaged* by someone other than the bug
creator.
Triaging bugs
`````````````
Reported bugs need prioritization, confirmation, and shouldn't go stale.
If you care about OpenStack stability but aren't wanting to actively
develop the roles and playbooks used within the "openstack-ansible"
project consider contributing in the area of bug triage, which helps
immensely. The whole process is described in the upstream
`Bug Triage Documentation`_.
.. _Bug Launchpad: https://bugs.launchpad.net/openstack-ansible
.. _Bug Triage Documentation: https://wiki.openstack.org/wiki/BugTriage
Submitting Code
---------------
* Write good commit messages. We follow the OpenStack
"`Git Commit Good Practice`_" guide. if you have any questions regarding how
to write good commit messages please review the upstream OpenStack
documentation.
* Changes to the project should be submitted for review via the Gerrit tool,
following the `workflow documented here`_.
* Pull requests submitted through GitHub will be ignored and closed without
regard.
* All feature additions/deletions should be accompanied by a blueprint/spec.
ie: adding additional active agents to neutron, developing a new service
role, etc...
* Before creating blueprint/spec an associated issue should be raised on
launchpad. This issue will be triaged and a determination will be made on
how large the change is and whether or not the change warrants a
blueprint/spec. Both features and bug fixes may require the creation of a
blueprint/spec. This requirement will be voted on by core reviewers and will
be based on the size and impact of the change.
* All blueprints/specs should be voted on and approved by core reviewers
before any associated code will be merged. For more information on
blueprints/specs please review the
`upstream OpenStack Blueprint documentation`_. At the time the
blueprint/spec is voted on a determination will be made whether or not the
work will be backported to any of the "released" branches.
* Patches should be focused on solving one problem at a time. If the review is
overly complex or generally large the initial commit will receive a "**-2**"
and the contributor will be asked to split the patch up across multiple
reviews. In the case of complex feature additions the design and
implementation of the feature should be done in such a way that it can be
submitted in multiple patches using dependencies. Using dependent changes
should always aim to result in a working build throughout the dependency
chain. Documentation is available for `advanced gerrit usage`_ too.
* All patch sets should adhere to the Ansible Style Guide listed here as well
as adhere to the `Ansible best practices`_ when possible.
* All changes should be clearly listed in the commit message, with an
associated bug id/blueprint along with any extra information where
applicable.
* Refactoring work should never include additional "rider" features. Features
that may pertain to something that was re-factored should be raised as an
issue and submitted in prior or subsequent patches.
.. _Git Commit Good Practice: https://wiki.openstack.org/wiki/GitCommitMessages
.. _workflow documented here: http://docs.openstack.org/infra/manual/developers.html#development-workflow
.. _upstream OpenStack Blueprint documentation: https://wiki.openstack.org/wiki/Blueprints
.. _advanced gerrit usage: http://www.mediawiki.org/wiki/Gerrit/Advanced_usage
.. _Ansible best practices: http://docs.ansible.com/playbooks_best_practices.html
Backporting
-----------
* Backporting is defined as the act of reproducing a change from another
branch. Unclean/squashed/modified cherry-picks and complete
reimplementations are OK.
* Backporting is often done by using the same code (via cherry picking), but
this is not always the case. This method is preferred when the cherry-pick
provides a complete solution for the targeted problem.
* When cherry-picking a commit from one branch to another the commit message
should be amended with any files that may have been in conflict while
performing the cherry-pick operation. Additionally, cherry-pick commit
messages should contain the original commit *SHA* near the bottom of the new
commit message. This can be done with ``cherry-pick -x``. Here's more
information on `Submitting a change to a branch for review`_.
* Every backport commit must still only solve one problem, as per the
guidelines in `Submitting Code`_.
* If a backport is a squashed set of cherry-picked commits, the original SHAs
should be referenced in the commit message and the reason for squashing the
commits should be clearly explained.
* When a cherry-pick is modified in any way, the changes made and the reasons
for them must be explicitly expressed in the commit message.
* Refactoring work must not be backported to a "released" branch.
.. _Submitting a change to a branch for review: http://www.mediawiki.org/wiki/Gerrit/Advanced_usage#Submitting_a_change_to_a_branch_for_review_.28.22backporting.22.29
Style Guide
-----------
When creating tasks and other roles for use in Ansible please create then
using the YAML dictionary format.
Example YAML dictionary format:
.. code-block:: yaml
- name: The name of the tasks
module_name:
thing1: "some-stuff"
thing2: "some-other-stuff"
tags:
- some-tag
- some-other-tag
Example what **NOT** to do:
.. code-block:: yaml
- name: The name of the tasks
module_name: thing1="some-stuff" thing2="some-other-stuff"
tags: some-tag
.. code-block:: yaml
- name: The name of the tasks
module_name: >
thing1="some-stuff"
thing2="some-other-stuff"
tags: some-tag
Usage of the ">" and "|" operators should be limited to Ansible conditionals
and command modules such as the Ansible ``shell`` or ``command``.
--------------
.. include:: navigation.txt

9
doc/source/developer-docs/extending.rst
View File

@ -1,7 +1,9 @@
Extending openstack-ansible
`Home <index.html>`_ OpenStack-Ansible Developer Documentation
Extending OpenStack-Ansible
===========================
The openstack-ansible project provides a basic OpenStack environment, but
The OpenStack-Ansible project provides a basic OpenStack environment, but
many deployers will wish to extend the environment based on their needs. This
could include installing extra services, changing package versions, or
overriding existing variables.
@ -254,3 +256,6 @@ The list of overrides available may be found by executing:
| grep -v "^#" \
| sort -u
--------------
.. include:: navigation.txt

5
doc/source/developer-docs/index.rst
View File

@ -9,10 +9,11 @@ Contents:
.. toctree::
:maxdepth: 2
quickstart-aio
scripts
playbooks
extending
scripts
quickstart-aio
contribute
Indices and tables

3
doc/source/developer-docs/navigation.txt Normal file
View File

@ -0,0 +1,3 @@
* `Documentation Home <../index.html>`_
* `Installation Guide <../install-guide/index.html>`_
* `Developer Documentation <index.html>`_

8
doc/source/developer-docs/playbooks.rst
View File

@ -1,7 +1,9 @@
`Home <index.html>`_ OpenStack-Ansible Developer Documentation
Playbooks
=========
The OpenStack Ansible playbooks are stored in the playbooks directory.
The OpenStack-Ansible playbooks are stored in the playbooks directory.
There are several top-level playbooks that are run to prepare the host machines
before actually deploying OpenStack and associated containers.
@ -46,3 +48,7 @@ OpenStack services:
* Neutron
* Heat
* Horizon
--------------
.. include:: navigation.txt

203
doc/source/developer-docs/quickstart-aio.rst
View File

@ -1,7 +1,9 @@
`Home <index.html>`_ OpenStack-Ansible Developer Documentation
Quick Start
===========
All-in-one (AIO) builds are a great way to perform an OpenStack Ansible build
All-in-one (AIO) builds are a great way to perform an OpenStack-Ansible build
for:
* a development environment
@ -45,11 +47,12 @@ Running a customized AIO build
There are four main steps for running a customized AIO build:
* Configuration *(this step is optional)*
* Initial bootstrap
* Initial host bootstrap
* Install and bootstrap Ansible
* Run playbooks
Start by cloning the openstack-ansible repository:
Start by cloning the openstack-ansible repository and changing into the
repository root directory:
.. code-block:: bash
@ -57,21 +60,54 @@ Start by cloning the openstack-ansible repository:
/opt/openstack-ansible
$ cd /opt/openstack-ansible
At this point, you can adjust which services are deployed within your AIO
build. Look at the top of ``scripts/bootstrap-aio.sh`` for several examples.
If you'd like to skip the deployment of ceilometer, you could run the
following:
Next switch the the applicable branch/tag you wish to deploy from. Note that
deploying from the head of a branch may result in an unstable build due to
changes in flight and upstream OpenStack changes. For a test (ie not a
development) build it is usually best to checkout the latest tagged version.
.. code-block:: bash
$ git checkout kilo
By default the scripts deploy all OpenStack services. At this point you may
optionally adjust which services are deployed within your AIO build. Look at
the ``DEPLOY_`` environment variables at the top of
``scripts/run-playbooks.sh`` for more details. For example, if you'd like to
skip the deployment of ceilometer, you would execute the following:
.. code-block:: bash
$ export DEPLOY_CEILOMETER="no"
Now you're ready to complete the bootstraps and run the playbooks:
Note that the scripts still build containers for any service that you disable,
but do not deploy the service.
In order for all the services to run, the host must be prepared with the
appropriate disks, packages, network configuration and a base configuration
for the OpenStack Deployment. This preparation is completed by executing:
.. code-block:: bash
$ scripts/bootstrap-aio.sh
If you wish to add any additional configuration entries for the OpenStack
configuration then this can be done now by editing
``/etc/openstack_deploy/user_variables.yml``. Please see the `Install Guide`_
for more details.
Note that the host bootstrap is not idempotent and should only be executed
once.
Once you're ready to deploy, bootstrap Ansible by executing:
.. code-block:: bash
$ scripts/bootstrap-ansible.sh
Finally, run the playbooks by executing:
.. code-block:: bash
$ scripts/run-playbooks.sh
The installation process will take a while to complete, but here are some
@ -81,6 +117,80 @@ general estimates:
* Virtual machines with SSD storage: ~ 45-60 minutes
* Systems with traditional hard disks: ~ 90-120 minutes
Once the playbooks have fully executed, you may experiment with various
settings changes in ``/etc/openstack_deploy/user_variable.yml`` and only
run individual playbooks. For example, to run the playbook for the
Keystone service, execute:
.. code-block:: bash
$ cd /opt/openstack-ansible/playbooks
$ openstack-ansible os-keystone-install.yml
.. _Install Guide: ../install-guide/
Rebuilding the AIO
------------------
Sometimes it may be useful to destroy all the containers and rebuild the AIO.
While it is preferred that the AIO is entirely destroyed and rebuilt, this
isn't always practical. As such the following may be executed instead:
.. code-block:: bash
$ # Move to the playbooks directory.
$ cd /opt/openstack-ansible/playbooks
$ # Destroy all of the running containers.
$ openstack-ansible lxc-containers-destroy.yml
$ # On the host stop all of the services that run locally and not
$ # within a container.
$ for i in \
$(ls /etc/init \
| grep -e "nova\|swift\|neutron" \
| awk -F'.' '{print $1}'); do \
service $i stop; \
done
$ # Uninstall the core services that were installed.
$ for i in $(pip freeze | grep -e "nova\|neutron\|keystone\|swift); do \
pip uninstall -y $i; done
$ # Remove crusty directories.
$ rm -rf /openstack /etc/{neutron,nova,swift} \
/var/log/{neutron,nova,swift}
There is a convenience script (``scripts/teardown.sh``) which will destroy
everything known within an environment. You should be aware that this script
will destroy whole environments and should be used WITH CAUTION.
After the teardown is complete, ``run-playbooks.sh`` may be executed again to
rebuild the AIO.
AIO Host Bootstrap Customisation
--------------------------------
The AIO makes a number of assumptions about the system it is being deployed
on. Many of these assumptions may be changed through the use of environment
variables which can be changed prior to the AIO host bootstrap.
As these options change on a regular basis it is best to examine each of the
scripts used to find the environment variables which can be overridden:
* ``scripts/bootstrap-aio.sh`` (this sets the AIO host up)
* ``scripts/bootstrap-ansible.sh`` (this sets Ansible up)
* ``scripts/scripts-library.sh`` (this is used by all the other scripts)
As an example, if you wish the Keystone Admin password to be a value which
you set (rather than the default of a random string), then execute:
.. code-block:: bash
export ADMIN_PASSWORD="secrete"
More details about the scripts used can be found in the `scripts page`_.
.. _scripts page: scripts.html
Quick AIO build on Rackspace Cloud
----------------------------------
@ -101,11 +211,12 @@ soon as the instance starts. Save this file as ``user_data.yml``:
- export ANSIBLE_FORCE_COLOR=true
- export PYTHONUNBUFFERED=1
- export REPO=https://github.com/openstack/openstack-ansible
- git clone ${REPO} /opt/os-ansible
- export BRANCH=kilo
- git clone -b ${BRANCH} ${REPO} /opt/openstack-ansible
- export DEPLOY_CEILOMETER="no"
- cd /opt/os-ansible && scripts/bootstrap-aio.sh
- cd /opt/os-ansible && scripts/bootstrap-ansible.sh
- cd /opt/os-ansible && scripts/run-playbooks.sh
- cd /opt/openstack-ansible && scripts/bootstrap-aio.sh
- cd /opt/openstack-ansible && scripts/bootstrap-ansible.sh
- cd /opt/openstack-ansible && scripts/run-playbooks.sh
output: { all: '| tee -a /var/log/cloud-init-output.log' }
Feel free to customize the YAML file to meet your requirements. As an example
@ -127,10 +238,74 @@ We can pass this YAML file to nova and build a Cloud Server at Rackspace:
Be sure to replace ``public_key_name`` with the name of the public key that
you prefer to use with your instance. Within a minute or so, your instance
should be running and the OpenStack Ansible installation will be in progress.
should be running and the OpenStack-Ansible installation will be in progress.
To follow along with the progress, ssh to your running instance and run:
To follow along with the progress, ssh to your running instance and execute:
.. code-block:: bash
tail -F /var/log/cloud-init-output.log
Reference Diagram for the AIO Build
-----------------------------------
Here is a basic diagram that attempts to illustrate what the resulting AIO
deployment looks like.
This diagram is not to scale and is not even 100% accurate, this diagram was
built for informational purposes only and should **ONLY** be used as such.
.. code-block:: text
------->[ ETH0 == Public Network ]
|
V [ * ] Socket Connections
[ HOST MACHINE ] [ <>v^ ] Network Connections
* ^ *
| | |-------------------------------------------------------
| | |
| |---------------->[ HAProxy ] |
| ^ |
| | |
| V |
| (BR-Interfaces)<------- |
| ^ * | |
*-[ LXC ]*--*----------------------|-----|------|----| |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | V * | |
| * | | [ Galera x3 ] |
| [ Memcached ]<------------| | | |
*-------*[ Rsyslog ]<--------------|--| | * |
| [ Repos Server x3 ]<------| ---|-->[ RabbitMQ x3 ] |
| [ Horizon x2 ]<-----------| | | |
| [ Nova api ec2 ]<---------|--| | |
| [ Nova api os ]<----------|->| | |
| [ Nova console ]<---------| | | |
| [ Nova Cert ]<------------|->| | |
| [ Ceilometer api ]<-------|->| | |
| [ Ceilometer collector ]<-|->| | |
| [ Cinder api ]<-----------|->| | |
| [ Glance api ]<-----------|->| | |
| [ Heat apis ]<------------|->| | [ Loop back devices ]*-*
| [ Heat engine ]<----------|->| | \ \ |
| ------>[ Nova api metadata ] | | | { LVM } { XFS x3 } |
| | [ Nova conductor ]<-------| | | * * |
| |----->[ Nova scheduler ]--------|->| | | | |
| | [ Keystone x3 ]<----------|->| | | | |
| | |--->[ Neutron agents ]*-------|--|---------------------------*
| | | [ Neutron server ]<-------|->| | | |
| | | |->[ Swift proxy ]<----------- | | | |
*-|-|-|-*[ Cinder volume ]*----------------------* | |
| | | | | | |
| | | ----------------------------------------- | |
| | ----------------------------------------- | | |
| | -------------------------| | | | |
| | | | | | |
| | V | | * |
---->[ Compute ]*[ Neutron linuxbridge ]<---| |->[ Swift storage ]-
--------------
.. include:: navigation.txt

53
doc/source/developer-docs/scripts.rst
View File

@ -1,10 +1,11 @@
`Home <index.html>`_ OpenStack-Ansible Developer Documentation
Included Scripts
================
The repository contains several helper scripts to manage gate jobs,
install base requirements, and update repository information. Invoke
these scripts from the top-level directory of the repository. For
example:
install base requirements, and update repository information. Execute
these scripts from the root of the respository clone. For example:
.. code:: bash
@ -37,6 +38,39 @@ The script also creates the ``openstack-ansible`` wrapper tool that provides
the variable files to match ``/etc/openstack_deploy/user_*.yml`` as
arguments to ``ansible-playbook`` as a convenience.
Development and Testing
^^^^^^^^^^^^^^^^^^^^^^^
run-playbooks.sh
----------------
The ``run-playbooks`` script is designed to be executed in development and
test environments and is also used for automated testing. It executes actions
which are definitely **not** suitable for production environments and must
therefore **not** be used for that purpose.
In order to scope the playbook execution there are several ``DEPLOY_``
environment variables available near the top of the script. These are used
by simply exporting an override before executing the script. For example,
to skip the execution of the Ceilometer playbook, execute:
.. code-block:: bash
export DEPLOY_CEILOMETER='no'
run-tempest.sh
--------------
The ``run-tempest.sh`` script runs Tempest tests from the first utility
container. This is primarily used for automated gate testing, but may also be
used through manual execution.
Configurable environment variables:
* ``TEMPEST_SCRIPT_PARAMETERS`` - Defines tests to run. Values are passed to
``openstack_tempest_gate.sh`` script, defined in the ``os_tempest`` role.
Defaults to ``scenario heat_api cinder_backup``.
Gating
^^^^^^
@ -52,7 +86,7 @@ Configurable environment variables:
* ``BOOTSTRAP_AIO`` - Boolean (yes/no) to run AIO bootstrap script. Defaults
to ``yes``.
* ``BOOTSTRAP_AIO`` - Boolean (yes/no) to run Ansible bootstrip script.
* ``BOOTSTRAP_ANSIBLE`` - Boolean (yes/no) to run Ansible bootstrip script.
Defaults to ``yes``.
* ``RUN_TEMPEST`` - Boolean (yes/no) to run Tempest tests. Defaults to
``yes``.
@ -78,15 +112,6 @@ the following rules due to Ansible conventions:
Ansible playbooks pass through ``ansible-playbook --syntax-check``
and ``ansible-lint``.
run-tempest.sh
--------------
The ``run-tempest.sh`` script runs Tempest tests from the first utility
container. The ``check-gate-commit.sh`` script usually invokes this
script after it completes the OSA deployment.
Configurable environment variables:
* ``TEMPEST_SCRIPT_PARAMETERS`` - Defines tests to run. Values are passed to
``openstack_tempest_gate.sh`` script, defined in the ``os_tempest`` role.
Defaults to ``scenario heat_api cinder_backup``.
.. include:: navigation.txt

2
doc/source/index.rst
View File

@ -3,7 +3,7 @@
You can adapt this file completely to your liking, but it should at least
contain the root `toctree` directive.
Welcome to openstack-ansible's documentation!
Welcome to OpenStack-Ansible's documentation!
=================================================

2
doc/source/install-guide/app-configfiles.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Appendix A. Configuration files
-------------------------------

41
doc/source/install-guide/app-resources.rst
View File

@ -1,38 +1,31 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Appendix B. Additional resources
Appendix B. Additional Resources
--------------------------------
These additional resources.
The following Ansible resources are useful to reference:
- `OpenStack Documentation <http://docs.openstack.org>`__
- `Ansible Documentation
<http://docs.ansible.com/ansible/>`_
- `OpenStack Developer
Documentation <http://developer.openstack.org/>`__
- `Ansible Best Practices
<http://docs.ansible.com/ansible/playbooks_best_practices.html>`_
- `OpenStack API Quick
Start <http://docs.openstack.org/api/quick-start/content/>`__
- `Ansible Configuration
<http://docs.ansible.com/ansible/intro_configuration.html>`_
- `OpenStack Block Storage (cinder) Developer
Documentation <http://docs.openstack.org/developer/cinder/>`__
The following OpenStack resources are useful to reference:
- `OpenStack Compute (nova) Developer
Documentation <http://docs.openstack.org/developer/nova/>`__
- `OpenStack Documentation <http://docs.openstack.org>`_
- `OpenStack Compute API v2 Developer
Guide <http://developer.openstack.org/api-ref-compute-v2.html>`__
- `OpenStack SDK, CLI and API Documentation
<http://developer.openstack.org/>`_
- `OpenStack Dashboard (horizon) Developer
Documentation <http://docs.openstack.org/developer/horizon/>`__
- `OpenStack API Quick Start
<http://docs.openstack.org/api/quick-start/content/>`_
- `OpenStack Identity (keystone) Developer
Documentation <http://docs.openstack.org/developer/keystone/>`__
- `OpenStack Image service (glance) Developer
Documentation <http://docs.openstack.org/developer/glance/>`__
- `OpenStack Object Storage (swift) Developer
Documentation <http://docs.openstack.org/developer/swift/>`__
- `OpenStack Project Developer Documentation
<http://docs.openstack.org/developer/>`_
--------------

2
doc/source/install-guide/configure-ceilometer.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the Ceilometer service (optional)
---------------------------------------------

2
doc/source/install-guide/configure-cinder-az.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Availability zones
------------------

2
doc/source/install-guide/configure-cinder-backup.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Backup
------

2
doc/source/install-guide/configure-cinder-nfs.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
NFS back-end
------------

2
doc/source/install-guide/configure-cinder.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the Block Storage service (optional)
------------------------------------------------

4
doc/source/install-guide/configure-creds.rst
View File

@ -1,11 +1,11 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring service credentials
-------------------------------
Configure credentials for each service in the
``/etc/openstack_deploy/*_secrets.yml`` files. Consider using `Ansible
Vault <http://docs.ansible.com/playbooks_vault.html>`__ to increase
Vault <http://docs.ansible.com/playbooks_vault.html>`_ to increase
security by encrypting any files containing credentials.
Adjust permissions on these files to restrict access by non-privileged

2
doc/source/install-guide/configure-glance.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the Image service
-----------------------------

2
doc/source/install-guide/configure-haproxy.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring HAProxy (optional)
------------------------------

2
doc/source/install-guide/configure-horizon.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring Horizon (optional)
------------------------------

2
doc/source/install-guide/configure-hostlist.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring target hosts
------------------------

2
doc/source/install-guide/configure-hypervisor.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the hypervisor (optional)
-------------------------------------

2
doc/source/install-guide/configure-keystone.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring Keystone (optional)
-------------------------------

6
doc/source/install-guide/configure-networking.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring target host networking
----------------------------------
@ -25,7 +25,7 @@ configure target host networking.
Use the same IP address ranges as the underlying physical network
interfaces or bridges configured in `the section called "Configuring
the network" <targethosts-network.html>`__. For example, if the
the network" <targethosts-network.html>`_. For example, if the
container network uses 203.0.113.0/24, the *``CONTAINER_MGMT_CIDR``*
should also use 203.0.113.0/24.
@ -44,7 +44,7 @@ configure target host networking.
addresses in the ranges defined in the previous step. This list
should include all IP addresses manually configured on target hosts
in the `the section called "Configuring the
network" <targethosts-network.html>`__, internal load balancers,
network" <targethosts-network.html>`_, internal load balancers,
service network bridge, deployment hosts and any other devices
to avoid conflicts during the automatic IP address generation process.

7
doc/source/install-guide/configure-openstack.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Overriding OpenStack Configuration Defaults
-------------------------------------------
@ -13,10 +13,11 @@ the `OpenStack Configuration Reference`_ through the use of a simple set of
configuration entries in ``/etc/openstack_deploy/user_variables.yml``.
This section provides guidance for how to make use of this facility. Further
guidance is available in the `Developer Documentation`_.
guidance is available in the Developer Documentation in the section titled
`Setting overrides in configuration files`_.
.. _OpenStack Configuration Reference: http://docs.openstack.org/draft/config-reference/
.. _Developer Documentation: ../developer-docs/extending.html#setting-overrides-in-configuration-files
.. _Setting overrides in configuration files: ../developer-docs/extending.html#setting-overrides-in-configuration-files
Overriding .conf files
~~~~~~~~~~~~~~~~~~~~~~

2
doc/source/install-guide/configure-prereq.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Prerequisites
-------------

2
doc/source/install-guide/configure-rabbitmq.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring RabbitMQ (optional)
-------------------------------

2
doc/source/install-guide/configure-sslcertificates.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Securing services with SSL certificates
---------------------------------------

6
doc/source/install-guide/configure-swift-add.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Add to existing deployment
--------------------------
@ -7,10 +7,10 @@ Complete the following procedure to deploy Object Storage on an
existing deployment.
#. `the section called "Configure and mount storage
devices" <configure-swift-devices.html>`__
devices" <configure-swift-devices.html>`_
#. `the section called "Configure an Object Storage
deployment" <configure-swift-config.html>`__
deployment" <configure-swift-config.html>`_
#. Optionally, allow all Identity users to use Object Storage by setting
``swift_allow_all_users`` in the ``user_variables.yml`` file to

2
doc/source/install-guide/configure-swift-config.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the service
-----------------------

4
doc/source/install-guide/configure-swift-devices.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Storage devices
---------------
@ -75,7 +75,7 @@ through ``sdg``.
$ mount /srv/node/sdg
To view an annotated example of the ``swift.yml`` file, see `Appendix A,
*OSA configuration files* <app-configfiles.html>`__.
*OSA configuration files* <app-configfiles.html>`_.
For the following mounted devices:

2
doc/source/install-guide/configure-swift-glance.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Integrate with the Image Service
--------------------------------

4
doc/source/install-guide/configure-swift-overview.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Overview
--------
@ -16,7 +16,7 @@ the ``swift`` section.
To view the configuration files, including information about which
variables are required and which are optional, see `Appendix A, *OSA
configuration files* <app-configfiles.html>`__.
configuration files* <app-configfiles.html>`_.
--------------

4
doc/source/install-guide/configure-swift-policies.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Storage Policies
----------------
@ -45,7 +45,7 @@ cluster:
specified when created.
For more information about storage policies, see: `Storage
Policies <http://docs.openstack.org/developer/swift/overview_policies.html>`__
Policies <http://docs.openstack.org/developer/swift/overview_policies.html>`_
--------------

6
doc/source/install-guide/configure-swift.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the Object Storage service (optional)
-------------------------------------------------
@ -21,10 +21,10 @@ modify the Object Storage configuration files to enable Object Storage
usage.
#. `the section called "Configure and mount storage
devices" <configure-swift-devices.html>`__
devices" <configure-swift-devices.html>`_
#. `the section called "Configure an Object Storage
deployment" <configure-swift-config.html>`__
deployment" <configure-swift-config.html>`_
#. Optionally, allow all Identity users to use Object Storage by setting
``swift_allow_all_users`` in the ``user_variables.yml`` file to

2
doc/source/install-guide/configure.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Chapter 5. Deployment configuration
-----------------------------------

2
doc/source/install-guide/deploymenthost-add.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the operating system
--------------------------------

4
doc/source/install-guide/deploymenthost-os.rst
View File

@ -1,10 +1,10 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Installing the operating system
-------------------------------
Install the `Ubuntu Server 14.04 (Trusty Tahr) LTS
64-bit <http://releases.ubuntu.com/14.04/>`__ operating system on the
64-bit <http://releases.ubuntu.com/14.04/>`_ operating system on the
deployment host with at least one network interface configured to access
the Internet or suitable local repositories.

2
doc/source/install-guide/deploymenthost-osa.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Installing source and dependencies
----------------------------------

2
doc/source/install-guide/deploymenthost-sshkeys.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring Secure Shell (SSH) keys
-----------------------------------

4
doc/source/install-guide/deploymenthost.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Chapter 3. Deployment host
--------------------------
@ -20,7 +20,7 @@ deployment host contains Ansible and orchestrates the OSA installation
on the target hosts. One of the target hosts, preferably one of the
infrastructure variants, can be used as the deployment host. To use a
deployment host as a target host, follow the steps in `Chapter 4,
*Target hosts* <targethosts.html>`__ on the deployment host. This
*Target hosts* <targethosts.html>`_ on the deployment host. This
guide assumes separate deployment and target hosts.
--------------

20
doc/source/install-guide/index.rst
View File

@ -1,13 +1,13 @@
OpenStack Ansible Installation Guide
OpenStack-Ansible Installation Guide
====================================
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Overview
^^^^^^^^
.. toctree::
.. toctree::
overview.rst
@ -22,7 +22,7 @@ Deployment host
Target hosts
^^^^^^^^^^^^
.. toctree::
.. toctree::
targethosts.rst
@ -30,7 +30,7 @@ Target hosts
Configuration
^^^^^^^^^^^^^
.. toctree::
.. toctree::
configure.rst
@ -38,7 +38,7 @@ Configuration
Installation
^^^^^^^^^^^^
.. toctree::
.. toctree::
install-foundation.rst
install-infrastructure.rst
@ -48,15 +48,15 @@ Installation
Operations
^^^^^^^^^^
.. toctree::
.. toctree::
ops.rst
Appendix
^^^^^^^^
Appendices
^^^^^^^^^^
.. toctree::
.. toctree::
app-configfiles.rst
app-resources.rst

2
doc/source/install-guide/install-foundation-run.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Running the foundation playbook
-------------------------------

2
doc/source/install-guide/install-foundation.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Chapter 6. Foundation playbooks
-------------------------------

2
doc/source/install-guide/install-infrastructure-run.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Running the infrastructure playbook
-----------------------------------

2
doc/source/install-guide/install-infrastructure-verify.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Verifying infrastructure operation
----------------------------------

2
doc/source/install-guide/install-infrastructure.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Chapter 7. Infrastructure playbooks
-----------------------------------

2
doc/source/install-guide/install-openstack-run.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Running the OpenStack playbook
------------------------------

4
doc/source/install-guide/install-openstack-utilitycontainer.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Utility container
-----------------
@ -14,7 +14,7 @@ For example, the tempest playbooks are installed on the utility
container since tempest testing does not need a container of its own.
For another example of using the utility container, see `the section
called "Verifying OpenStack
operation" <install-openstack-verify.html>`__.
operation" <install-openstack-verify.html>`_.
--------------

2
doc/source/install-guide/install-openstack-verify.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Verifying OpenStack operation
-----------------------------

4
doc/source/install-guide/install-openstack.rst
View File

@ -1,9 +1,9 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Chapter 8. OpenStack playbooks
------------------------------
.. toctree::
.. toctree::
install-openstack-run.rst
install-openstack-utilitycontainer.rst

118
doc/source/install-guide/navigation.txt
View File

@ -1,115 +1,3 @@
`Main Index <index.html>`__
----------
- `2. Overview <overview.html>`__
- `About OpenStack Ansible Deployment <overview-osa>`__
- `Ansible <overview-ansible.html>`__
- `Linux Containers (LXC) <overview-lxc.html>`__
- `Host layout <overview-hostlayout.html>`__
- `Host networking <overview-hostnetworking.html>`__
- `OpenStack Networking <overview-neutron.html>`__
- `Installation requirements <overview-requirements.html>`__
- `Installation workflow <overview-workflow.html>`__
- `3. Deployment host <deploymenthost.html>`__
- `Installing the operating system <deploymenthost-os.html>`__
- `Configuring the operating
system <deploymenthost-add.html>`__
- `Installing source and
dependencies <deploymenthost-osa.html>`__
- `Configuring Secure Shell (SSH)
keys <deploymenthost-sshkeys.html>`__
- `4. Target hosts <targethosts.html>`__
- `Installing the operating system <targethosts-os.html>`__
- `Configuring Secure Shell (SSH)
keys <targethosts-sshkeys.html>`__
- `Configuring the operating system <targethosts-add.html>`__
- `Configuring LVM <targethosts-configlvm.html>`__
- `Configuring the network <targethosts-network.html>`__
- `Reference
architecture <targethosts-networkrefarch.html>`__
- `Configuring the network on a target
host <targethosts-networkexample.html>`__
- `5. Deployment configuration <configure.html>`__
- `Prerequisites <configure-prereq.html>`__
- `Configuring target host
networking <configure-networking.html>`__
- `Configuring target hosts <configure-hostlist.html>`__
- `Configuring service credentials <configure-creds.html>`__
- `Configuring the hypervisor
(optional) <configure-hypervisor.html>`__
- `Configuring the Image service
(optional) <configure-glance.html>`__
- `Configuring the Block Storage service
(optional) <configure-cinder.html>`__
- `NFS back-end <configure-cinder-nfs.html>`__
- `Backup <configure-cinder-backup.html>`__
- `Availability zones <configure-cinder-az.html>`__
- `Configuring the Object Storage service
(optional) <configure-swift.html>`__
- `Overview <configure-swift-overview.html>`__
- `Storage devices <configure-swift-devices.html>`__
- `Object Storage service <configure-swift-config.html>`__
- `Integrate with the Image Service
<configure-swift-glance.html>`__
- `Add to existing deployment <configure-swift-add.html>`__
- `Policies <configure-swift-policies.html>`__
- `Configuring HAProxy (optional) <configure-haproxy.html>`__
- `Configuring Horizon (optional) <configure-horizon.html>`__
- `Configuring Keystone (optional) <configure-keystone.html>`__
- `Configuring RabbitMQ (optional) <configure-rabbitmq.html>`__
- `Securing services with SSL certificates
<configure-sslcertificates.html>`__
- `6. Installation <install.html>`__
- `Foundation components <install-foundation.html>`__
- `Running the foundation
playbook <install-foundation-run.html>`__
- `Infrastructure components <install-infrastructure.html>`__
- `Running the infrastructure
playbook <install-infrastructure-run.html>`__
- `Verifying infrastructure
operation <install-infrastructure-verify.html>`__
- `OpenStack components <install-openstack.html>`__
- `Running the OpenStack
playbook <install-openstack-run.html>`__
- `Utility Container
Overview <install-openstack-utilitycontainer.html>`__
- `Verifying OpenStack
operation <install-openstack-verify.html>`__
- `7. Operations <ops.html>`__
- `Adding a compute host <ops-addcomputehost.html>`__
- `Galera cluster maintenance <ops-galera.html>`__
- `Removing nodes <ops-galera-remove.html>`__
- `Starting a cluster <ops-galera-start.html>`__
- `Cluster recovery <ops-galera-recovery.html>`__
- `Single-node failure <ops-galera-recoverysingle.html>`__
- `Multi-node failure <ops-galera-recoverymulti.html>`__
- `Complete failure <ops-galera-recoverycomplete.html>`__
- `Rebuilding a
container <ops-galera-recoverycontainer.html>`__
- `A. OSA configuration files <app-configfiles.html>`__
- `B. Additional resources <app-resources.html>`__
* `Documentation Home <../index.html>`_
* `Installation Guide <index.html>`_
* `Developer Documentation <../developer-docs/index.html>`_

4
doc/source/install-guide/ops-addcomputehost.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Adding a compute host
---------------------
@ -7,7 +7,7 @@ Use the following procedure to add a compute host to an operational
cluster.
#. Configure the host as a target host. See `Chapter 4, *Target
hosts* <ch-hosts-target.html>`__ for more information.
hosts* <ch-hosts-target.html>`_ for more information.
#. Edit the ``/etc/openstack_deploy/openstack_user_config.yml`` file and
add the host to the ``compute_hosts`` stanza.

2
doc/source/install-guide/ops-galera-recovery.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Galera cluster recovery
-----------------------

2
doc/source/install-guide/ops-galera-recoverycomplete.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Complete failure
----------------

2
doc/source/install-guide/ops-galera-recoverycontainer.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Rebuilding a container
----------------------

4
doc/source/install-guide/ops-galera-recoverymulti.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Multi-node failure
------------------
@ -33,7 +33,7 @@ recover cannot join the cluster because it no longer exists.
server indicates ``non-Primary`` because it cannot achieve quorum.
#. Run the following command to
`rebootstrap <http://galeracluster.com/documentation-webpages/quorumreset.html#id1>`__
`rebootstrap <http://galeracluster.com/documentation-webpages/quorumreset.html#id1>`_
the operational node into the cluster.
.. code-block:: bash

2
doc/source/install-guide/ops-galera-recoverysingle.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Single-node failure
-------------------

2
doc/source/install-guide/ops-galera-remove.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Removing nodes
--------------

2
doc/source/install-guide/ops-galera-start.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Starting a cluster
------------------

2
doc/source/install-guide/ops-galera.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Galera cluster maintenance
--------------------------

2
doc/source/install-guide/ops-troubleshooting-containernetworking.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Container networking issues
---------------------------

2
doc/source/install-guide/ops-troubleshooting.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Troubleshooting
---------------

2
doc/source/install-guide/ops.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Chapter 9. Operations
---------------------

20
doc/source/install-guide/overview-ansible.rst
View File

@ -1,17 +1,17 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Ansible
-------
OpenStack Ansible Deployment uses a combination of Ansible and
Linux Containers (LXC) to install and manage OpenStack. Ansible
provides an automation platform to simplify system and application
deployment. Ansible manages systems using Secure Shell (SSH)
OpenStack-Ansible Deployment uses a combination of Ansible and
Linux Containers (LXC) to install and manage OpenStack. Ansible
provides an automation platform to simplify system and application
deployment. Ansible manages systems using Secure Shell (SSH)
instead of unique protocols that require remote daemons or agents.
Ansible uses *playbooks* written in the YAML language for orchestration.
For more information, see `Ansible - Intro to
Playbooks <http://docs.ansible.com/playbooks_intro.html>`__.
Playbooks <http://docs.ansible.com/playbooks_intro.html>`_.
In this guide, we refer to the host running Ansible playbooks as
the *deployment host* and the hosts on which Ansible installs OSA as the
@ -19,13 +19,13 @@ the *deployment host* and the hosts on which Ansible installs OSA as the
A recommended minimal layout for deployments involves five target
hosts in total: three infrastructure hosts, one compute host, and one
logging host. All hosts require three network interfaces. More
information on setting up target hosts can be found in `the section
called "Host layout" <overview-hostlayout.html>`__.
logging host. All hosts require three network interfaces. More
information on setting up target hosts can be found in `the section
called "Host layout" <overview-hostlayout.html>`_.
For more information on physical, logical, and virtual network
interfaces within hosts see `the section called "Host
networking" <overview-hostnetworking.html>`__.
networking" <overview-hostnetworking.html>`_.
--------------

6
doc/source/install-guide/overview-hostlayout.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Host layout
-----------
@ -14,8 +14,8 @@ The recommended layout contains a minimum of five hosts (or servers).
To use the optional Block Storage (cinder) service, a sixth host is
recommended. Block Storage hosts require an LVM volume group named
*cinder-volumes*. See `the section called "Installation
requirements" <overview-requirements.html>`__ and `the section
called "Configuring LVM" <targethosts-configlvm.html>`__ for more information.
requirements" <overview-requirements.html>`_ and `the section
called "Configuring LVM" <targethosts-configlvm.html>`_ for more information.
The hosts are called *target hosts* because Ansible deploys the OSA
environment within these hosts. The OSA environment also recommends a

8
doc/source/install-guide/overview-hostnetworking.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Host networking
---------------
@ -29,7 +29,7 @@ random names for ``veth`` pairs.
The relationship between physical interfaces, logical interfaces,
bridges, and virtual interfaces within containers is shown in
`Figure 2.2, "Network
components" <overview-hostnetworking.html#fig_overview_networkcomponents>`__.
components" <overview-hostnetworking.html#fig_overview_networkcomponents>`_.
 
@ -93,7 +93,7 @@ Target hosts can contain the following network bridges:
layer 2 connectivity.
`Figure 2.3, "Container network
architecture" <overview-hostnetworking.html#fig_overview_networkarch-container>`__
architecture" <overview-hostnetworking.html#fig_overview_networkarch-container>`_
provides a visual representation of network components for services in
containers.
@ -106,7 +106,7 @@ containers.
By default, OSA installs the Compute service in a bare metal
environment rather than within a container. `Figure 2.4, "Bare/Metal
network
architecture" <overview-hostnetworking.html#fig_overview_networkarch-bare>`__
architecture" <overview-hostnetworking.html#fig_overview_networkarch-bare>`_
provides a visual representation of the unique layout of network
components on a Compute host.

2
doc/source/install-guide/overview-lxc.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Linux Containers (LXC)
----------------------

6
doc/source/install-guide/overview-neutron.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
OpenStack Networking
--------------------
@ -6,7 +6,7 @@ OpenStack Networking
OpenStack Networking (neutron) is configured to use a DHCP agent, L3
Agent and Linux Bridge agent within a networking agents container.
`Figure 2.5, "Networking agents
containers" <overview-neutron.html#fig_overview_neutron-agents>`__
containers" <overview-neutron.html#fig_overview_neutron-agents>`_
shows the interaction of these agents, network components, and
connection to a physical network.
@ -17,7 +17,7 @@ connection to a physical network.
.. image:: figures/networking-neutronagents.png
The Compute service uses the KVM hypervisor. `Figure 2.6, "Compute
hosts" <overview-neutron.html#fig_overview_neutron-compute>`__ shows
hosts" <overview-neutron.html#fig_overview_neutron-compute>`_ shows
the interaction of instances, Linux Bridge agent, network components,
and connection to a physical network.

10
doc/source/install-guide/overview-osa.rst
View File

@ -1,6 +1,6 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
About OpenStack Ansible Deployment
About OpenStack-Ansible Deployment
----------------------------------
OpenStack-Ansible uses the Ansible IT automation framework to
@ -8,9 +8,9 @@ create an OpenStack cluster on Ubuntu Linux. OpenStack components are
installed into Linux Containers (LXC) for isolation and ease of
maintenance.
| OpenStack Ansible Deployment
| OpenStack-Ansible Deployment
This documentation is intended for deployers of the OpenStack Ansible
This documentation is intended for deployers of the OpenStack-Ansible
deployment system who are interested in installing an OpenStack. The
document is for informational purposes only and is provided "AS IS."
@ -21,7 +21,7 @@ purposes only. We do not intend our use or display of other companies"
tradenames, trademarks, or service marks to imply a relationship with,
or endorsement or sponsorship of us by, these other companies.
`OpenStack.org <http://www.openstack.org>`__
`OpenStack.org <http://www.openstack.org>`_
.. include:: navigation.txt

2
doc/source/install-guide/overview-requirements.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Installation requirements
-------------------------

2
doc/source/install-guide/overview-workflow.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Installation workflow
---------------------

2
doc/source/install-guide/overview.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Chapter 2. Overview
-------------------

2
doc/source/install-guide/targethosts-add.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the operating system
--------------------------------

4
doc/source/install-guide/targethosts-configlvm.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring LVM
---------------
@ -21,4 +21,4 @@ Configuring LVM
--------------
.. include:: navigation.txt
.. include:: navigation.txt

6
doc/source/install-guide/targethosts-network.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the network
-----------------------
@ -41,8 +41,8 @@ following optional components:
- Storage network subinterface on the ``bond0`` interface and
``br-storage`` bridge with a static IP address.
For more information, see `OpenStack Ansible
Networking <https://github.com/openstack/openstack-ansible/blob/master/etc/network/README.rst>`__.
For more information, see `OpenStack-Ansible
Networking <https://github.com/openstack/openstack-ansible/blob/master/etc/network/README.rst>`_.
--------------

6
doc/source/install-guide/targethosts-networkexample.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring the network on a target host
----------------------------------------
@ -6,9 +6,9 @@ Configuring the network on a target host
This example uses the following parameters to configure networking on a
single target host. See `Figure 4.2, "Target hosts for infrastructure,
networking, and storage
services" <targethosts-networkexample.html#fig_hosts-target-network-containerexample>`__
services" <targethosts-networkexample.html#fig_hosts-target-network-containerexample>`_
and `Figure 4.3, "Target hosts for Compute
service" <targethosts-networkexample.html#fig_hosts-target-network-bareexample>`__
service" <targethosts-networkexample.html#fig_hosts-target-network-bareexample>`_
for a visual representation of these parameters in the architecture.
- VLANs:

2
doc/source/install-guide/targethosts-networkrefarch.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Reference architecture
----------------------

2
doc/source/install-guide/targethosts-os.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Installing the operating system
-------------------------------

2
doc/source/install-guide/targethosts-sshkeys.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Configuring Secure Shell (SSH) keys
-----------------------------------

2
doc/source/install-guide/targethosts.rst
View File

@ -1,4 +1,4 @@
`Home <index.html>`__ OpenStack Ansible Installation Guide
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Chapter 4. Target hosts
-----------------------