openstack/openstack-ansible
Code Issues Proposed changes

[DOCS} Further edits, corrects to draft install

Browse Source 
Change-Id: I25df03899c3052e86cce8cb3797f605993c25a37
Implements: blueprint osa-install-guide-overhaul
This commit is contained in:
Alexandra
2016-08-25 14:33:55 +01:00
committed by Travis Truman
parent 8252d313be
commit 192efa5d63
26 changed files with 230 additions and 336 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/install-guide-revised-draft/app-advanced-config-options.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
=================================== ===================================
Appendix E: Advanced configuration Appendix E: Advanced configuration
=================================== ===================================

2
doc/source/install-guide-revised-draft/app-advanced-config-override.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
=========================================== ===========================================
Overriding OpenStack configuration defaults Overriding OpenStack configuration defaults
=========================================== ===========================================

6
doc/source/install-guide-revised-draft/app-advanced-config-security.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
.. _security_hardening: .. _security_hardening:
================== ==================
@@ -34,8 +32,8 @@ an environment using a playbook supplied with OpenStack-Ansible:
# Apply security hardening configurations # Apply security hardening configurations
openstack-ansible security-hardening.yml openstack-ansible security-hardening.yml
For more details on the security configurations that will be applied, refer to Refer to the `openstack-ansible-security`_ documentation for more details on
the `openstack-ansible-security`_ documentation. Review the `Configuration`_ the security configurations. Review the `Configuration`_
section of the openstack-ansible-security documentation to find out how to section of the openstack-ansible-security documentation to find out how to
fine-tune certain security configurations. fine-tune certain security configurations.

2
doc/source/install-guide-revised-draft/app-advanced-config-sslcertificates.rst
View File

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

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

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
================================= =================================
Appendix A: Configuration files Appendix A: Configuration files
================================= =================================

9
doc/source/install-guide-revised-draft/app-custom-layouts.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
================================================== ==================================================
Appendix C: Customizing host and service layouts Appendix C: Customizing host and service layouts
================================================== ==================================================
@@ -49,7 +47,7 @@ variables to any component containers on the specific host.
.. note:: .. note::
Our current recommendation is for new inventory groups, particularly for new We recommend new inventory groups, particularly for new
services, to be defined using a new file in the ``conf.d/`` directory in services, to be defined using a new file in the ``conf.d/`` directory in
order to manage file size. order to manage file size.
@@ -99,9 +97,6 @@ groups in this way allows flexible targeting of roles and tasks.
Customizing existing components Customizing existing components
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Numerous customization scenarios are possible, but three popular ones are
presented here as starting points and also as common recipes.
Deploying directly on hosts Deploying directly on hosts
--------------------------- ---------------------------
@@ -114,7 +109,7 @@ is the same for a service deployed directly onto the host.
.. note:: .. note::
The ``cinder_volume`` component is also deployed directly on the host by The ``cinder-volume`` component is also deployed directly on the host by
default. See the ``env.d/cinder.yml`` file for this example. default. See the ``env.d/cinder.yml`` file for this example.
Omit a service or component from the deployment Omit a service or component from the deployment

2
doc/source/install-guide-revised-draft/app-resources.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
================================= =================================
Appendix B: Additional resources Appendix B: Additional resources
================================= =================================

2
doc/source/install-guide-revised-draft/app-security.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`__ OpenStack-Ansible Installation Guide
===================== =====================
Appendix D: Security Appendix D: Security
===================== =====================

2
doc/source/install-guide-revised-draft/targethosts-networkexample.rst → doc/source/install-guide-revised-draft/app-targethosts-networkexample.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
=========================================== ===========================================
Appendix F: Sample interface configurations Appendix F: Sample interface configurations
=========================================== ===========================================

8
doc/source/install-guide-revised-draft/app.rst
View File

@@ -2,8 +2,6 @@
Appendices Appendices
========== ==========
`Home <index.html>`_ OpenStack-Ansible Installation Guide
.. toctree:: .. toctree::
:maxdepth: 2 :maxdepth: 2
@@ -12,4 +10,8 @@ Appendices
app-custom-layouts.rst app-custom-layouts.rst
app-security.rst app-security.rst
app-advanced-config-options.rst app-advanced-config-options.rst
targethosts-networkexample.rst app-targethosts-networkexample.rst
--------------
.. include:: navigation.txt

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

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
=============================== ===============================
Configuring service credentials Configuring service credentials
=============================== ===============================
@@ -16,7 +14,7 @@ users.
The following options configure passwords for the web interfaces. The following options configure passwords for the web interfaces.
- ``keystone_auth_admin_password`` configures the ``admin`` tenant * ``keystone_auth_admin_password`` configures the ``admin`` tenant
password for both the OpenStack API and dashboard access. password for both the OpenStack API and dashboard access.
.. note:: .. note::

16
doc/source/install-guide-revised-draft/configure-initial.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
================================= =================================
Initial environment configuration Initial environment configuration
================================= =================================
@@ -28,13 +26,13 @@ to the deployment of your OpenStack environment.
The file is heavily commented with details about the various options. The file is heavily commented with details about the various options.
There are various types of physical hardware that are able to use containers Configuration in ``openstack_user_config.yml`` defines which hosts
deployed by OpenStack-Ansible. For example, hosts listed in the will run the containers and services deployed by OpenStack-Ansible. For
``shared-infra_hosts`` run containers for many of the shared services that example, hosts listed in the ``shared-infra_hosts`` run containers for many of
your OpenStack environment requires. Some of these services include databases, the shared services that your OpenStack environment requires. Some of these
memcached, and RabbitMQ. There are several other host types that contain services include databases, memcached, and RabbitMQ. There are several other
other types of containers and all of these are listed in host types that contain other types of containers and all of these are listed
``openstack_user_config.yml``. in ``openstack_user_config.yml``.
For details about how the inventory is generated from the environment For details about how the inventory is generated from the environment
configuration, see :ref:`developer-inventory`. configuration, see :ref:`developer-inventory`.

26
doc/source/install-guide-revised-draft/configure-user-config-examples.rst
View File

@@ -1,8 +1,6 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide ==================================
openstack_user_config.yml examples
====================================== ==================================
``openstack_user_config.yml`` examples
======================================
The ``/etc/openstack_deploy/openstack_user_config.yml`` configuration file The ``/etc/openstack_deploy/openstack_user_config.yml`` configuration file
contains parameters to configure target host, and target host networking. contains parameters to configure target host, and target host networking.
@@ -11,26 +9,12 @@ Examples are provided below for a test environment and production environment.
Test environment Test environment
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~
.. TODO Parse openstack_user_config.yml examples when done. .. TODO include openstack_user_config.yml examples when done.
Production environment Production environment
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
.. TODO Parse openstack_user_config.yml examples when done. .. TODO include openstack_user_config.yml examples when done.
Setting an MTU on a default lxc bridge (lxcbr0)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To modify a container MTU it is required to set ``lxc_net_mtu`` to
a value other than 1500 in ``user_variables.yml``.
.. note::
It is necessary to modify the ``provider_networks`` subsection to
reflect the change.
This will define the mtu on the lxcbr0 interface. An ifup/ifdown will
be required if the interface is already up for the changes to take effect.
-------------- --------------

21
doc/source/install-guide-revised-draft/configure.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
======================== ========================
Deployment configuration Deployment configuration
======================== ========================
@@ -14,22 +12,17 @@ Deployment configuration
.. figure:: figures/installation-workflow-configure-deployment.png .. figure:: figures/installation-workflow-configure-deployment.png
:width: 100% :width: 100%
Installation workflow
Ansible references a handful of files containing mandatory and optional Ansible references a handful of files containing mandatory and optional
configuration directives. These files must be modified to define the configuration directives. Modify these files to define the
target environment before running the Ansible playbooks. Configuration target environment before running the Ansible playbooks. Configuration
tasks include: tasks include:
- Target host networking to define bridge interfaces and * Target host networking to define bridge interfaces and
networks. networks.
* A list of target hosts on which to install the software.
- A list of target hosts on which to install the software. * Virtual and physical network relationships for OpenStack
Networking (neutron).
- Virtual and physical network relationships for OpenStack * Passwords for all services.
Networking (neutron).
- Passwords for all services.
-------------- --------------

6
doc/source/install-guide-revised-draft/deploymenthost.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
=============== ===============
Deployment host Deployment host
=============== ===============
@@ -7,8 +5,6 @@ Deployment host
.. figure:: figures/installation-workflow-deploymenthost.png .. figure:: figures/installation-workflow-deploymenthost.png
:width: 100% :width: 100%
**Installation workflow**
When installing OpenStack in a production environment, we recommend using a When installing OpenStack in a production environment, we recommend using a
separate deployment host which contains Ansible and orchestrates the separate deployment host which contains Ansible and orchestrates the
OpenStack-Ansible installation on the target hosts. In a test environment, we OpenStack-Ansible installation on the target hosts. In a test environment, we
@@ -23,7 +19,7 @@ Installing the operating system
Install the `Ubuntu Server 14.04 (Trusty Tahr) LTS 64-bit Install the `Ubuntu Server 14.04 (Trusty Tahr) LTS 64-bit
<http://releases.ubuntu.com/14.04/>`_ operating system on the <http://releases.ubuntu.com/14.04/>`_ operating system on the
deployment host. Configure at least one network interface to deployment host. Configure at least one network interface to
access the Internet or suitable local repositories. access the internet or suitable local repositories.
Configuring the operating system Configuring the operating system
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

12
doc/source/install-guide-revised-draft/index.rst
View File

@@ -5,11 +5,6 @@ OpenStack-Ansible Installation Guide - DRAFT
This is a draft revision of the install guide for Newton This is a draft revision of the install guide for Newton
and is currently under development. and is currently under development.
`Home <index.html>`_ OpenStack-Ansible Installation Guide
Table of contents
~~~~~~~~~~~~~~~~~
.. toctree:: .. toctree::
:maxdepth: 2 :maxdepth: 2
@@ -19,3 +14,10 @@ Table of contents
configure.rst configure.rst
installation.rst installation.rst
app.rst app.rst
Third-party trademarks and tradenames appearing in this document are the
property of their respective owners. Such third-party trademarks have
been printed in caps or initial caps and are used for referential
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.

15
doc/source/install-guide-revised-draft/installation.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
============ ============
Installation Installation
============ ============
@@ -13,19 +11,19 @@ The installation process requires running three main playbooks:
- The ``setup-infrastructure.yml`` Ansible infrastructure playbook installs - The ``setup-infrastructure.yml`` Ansible infrastructure playbook installs
infrastructure services: memcached, the repository server, Galera, RabbitMQ, infrastructure services: memcached, the repository server, Galera, RabbitMQ,
Rsyslog, and configures Rsyslog. and Rsyslog.
- The ``setup-openstack.yml`` OpenStack playbook installs OpenStack services, - The ``setup-openstack.yml`` OpenStack playbook installs OpenStack services,
including the Identity service (keystone), Image service (glance), including the Identity service (keystone), Image service (glance),
Block Storage (cinder), Compute service (nova), OpenStack Networking Block Storage (cinder), Compute service (nova), OpenStack Networking
(neutron), Orchestration (heat), Dashboard (horizon), Telemetry service (neutron), Orchestration (heat), Dashboard (horizon), Telemetry service
(ceilometer and aodh), Object Storage service (swift), and OpenStack (ceilometer and aodh), Object Storage service (swift), and OpenStack
bare metal provisioning (ironic). Bare Metal provisioning (ironic).
Checking the integrity of your configuration files Checking the integrity of your configuration files
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Before running any playbook, check the integrity of your configuration files: Before running any playbook, check the integrity of your configuration files.
#. Ensure all files edited in ``/etc/`` are Ansible #. Ensure all files edited in ``/etc/`` are Ansible
YAML compliant. Guidelines can be found here: YAML compliant. Guidelines can be found here:
@@ -154,10 +152,6 @@ Verifying OpenStack operation
.. TODO Add procedures to test different layers of the OpenStack environment .. TODO Add procedures to test different layers of the OpenStack environment
Verify basic operation of the OpenStack API and dashboard.
**Verifying the API**
The utility container provides a CLI environment for additional The utility container provides a CLI environment for additional
configuration and testing. configuration and testing.
@@ -204,7 +198,8 @@ configuration and testing.
| e59e4379730b41209f036bbeac51b181 | keystone | | e59e4379730b41209f036bbeac51b181 | keystone |
+----------------------------------+--------------------+ +----------------------------------+--------------------+
**Verifying the Dashboard** Verifying the Dashboard (horizon)
---------------------------------
#. With a web browser, access the Dashboard using the external load #. With a web browser, access the Dashboard using the external load
balancer IP address defined by the ``external_lb_vip_address`` option balancer IP address defined by the ``external_lb_vip_address`` option

122
doc/source/install-guide-revised-draft/overview-host-layout.rst
View File

@@ -1,104 +1,98 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
.. _host-layout: .. _host-layout:
=========== ===========
Host layout Host layout
=========== ===========
The hosts are called target hosts because Ansible deploys the * Infrastructure:
OpenStack-Ansible environment within these hosts. We recommend a
deployment host from which Ansible orchestrates the deployment
process. One of the target hosts can function as the deployment host.
If the optional Block Storage (cinder) service is used, we recommend * Galera
using an additional host. Block Storage hosts require an LVM volume group named * RabbitMQ
``cinder-volumes``. See `the section called "Installation * Memcached
requirements" <overview-requirements.html>`_ and `the section * Repository
called "Configuring LVM" <targethosts-prepare.html#configuring-lvm>`_
for more information.
Use at least one load balancer to manage the traffic among * (Optional) Load Balancer hosts:
the target hosts. You can use any type of load balancer such as a hardware
appliance or software like `HAProxy <http://www.haproxy.org/>`_. We recommend
using physical load balancers for a production environment.
A Control Plane and Infrastucture target host contains the following * HAProxy
services:
- Infrastructure: .. note::
- Galera Use at least one load balancer to manage the traffic among
the target hosts. You can use any type of load balancer such as a hardware
appliance or software like `HAProxy <http://www.haproxy.org/>`_. We recommend
using physical load balancers for a production environment.
- RabbitMQ * Log aggregation host:
- Memcached * Rsyslog
- Logging * OpenStack API services:
- Repository * Identity (keystone)
* Image service (glance)
* Compute management (nova)
* Networking (neutron)
* Orchestration (heat)
* Dashboard (horizon)
- OpenStack: * Compute hosts:
- Identity (keystone) * Compute virtualization (``nova-compute``)
* Networking agent (``neutron-agent``)
- Image service (glance) * (Optional) Storage hosts:
- Compute management (nova) * Block Storage scheduler (``cinder-scheduler``)
* Block Storage volumes (``cinder-volume``)
- Networking (neutron) .. note::
- Orchestration (heat)
- Dashboard (horizon)
Log aggregation hosts contain the following services:
- Rsyslog
Compute target hosts contain the following services:
- Compute virtualization
- Logging
(Optional) Storage target hosts contain the following services:
- Block Storage scheduler
- Block Storage volumes
If the optional Block Storage (cinder) service is used, we recommend
using an additional host. 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-prepare.html#configuring-lvm>`_
for more information.
Test environment Test environment
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~
The test environment is a minimal set of components to deploy a working The test environment is a minimal set of components to deploy a working
OpenStack-ansible environment. It consists of three hosts in total: one OpenStack-Ansible environment. It consists of three hosts in total:
control plane and infrastructure host, one compute host and one storage host.
It also has the following features:
- One Network Interface Card (NIC) for each target host * One control plane and infrastructure host
- No log aggregation target host * One compute host
- File-backed storage for glance and nova * One storage host
- LVM-backed cinder
It contains the following features:
* One Network Interface Card (NIC) for each target host
* No log aggregation host
* File-backed storage for glance and nova
* LVM-backed cinder
.. image:: figures/arch-layout-test.png .. image:: figures/arch-layout-test.png
:width: 100% :width: 100%
:alt: Test environment host layout :alt: Test environment host layout
Production environment Production environment
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
The layout for a production environment involves seven target The production environment is a more complicated set of components to deploy
hosts in total: three control plane and infrastructure hosts, two compute a working OpenStack-Ansible environment. The layout for a production
hosts, one storage host and one log aggregation host. It also has the environment involves seven target hosts in total:
following features:
- Bonded NICs. * Three control plane and infrastructure hosts
- NFS/Ceph-backed storage for nova, glance, and cinder. * Two compute hosts
* One storage host
* One log aggregation host
All hosts will need at least one networking It contains the following features:
* Bonded NICs
* NFS/Ceph-backed storage for nova, glance, and cinder
All hosts need at least one networking
interface, but we recommend multiple bonded interfaces. interface, but we recommend multiple bonded interfaces.
For more information on physical, logical, and virtual network For more information on physical, logical, and virtual network

33
doc/source/install-guide-revised-draft/overview-network-arch.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
.. _network-architecture: .. _network-architecture:
==================== ====================
@@ -93,10 +91,9 @@ Target hosts contain the following network bridges:
- Provides management of and communication among infrastructure and - Provides management of and communication among infrastructure and
OpenStack services. OpenStack services.
- Manually creates and attaches to a physical or logical interface, - Attaches to a physical or logical interface, typically a ``bond0`` VLAN
typically a ``bond0`` VLAN subinterface. Also attaches to ``eth1`` subinterface. Also attaches to ``eth1`` in each container. The container
in each container. The container network interface network interface is configurable in ``openstack_user_config.yml``.
is configurable in ``openstack_user_config.yml``.
- Storage ``br-storage``: - Storage ``br-storage``:
@@ -105,10 +102,10 @@ Target hosts contain the following network bridges:
- Provides segregated access to Block Storage devices between - Provides segregated access to Block Storage devices between
Compute and Block Storage hosts. Compute and Block Storage hosts.
- Manually creates and attaches to a physical or logical interface, - Attaches to a physical or logical interface, typically a ``bond0`` VLAN
typically a ``bond0`` VLAN subinterface. Also attaches to ``eth2`` subinterface. Also attaches to ``eth2`` in each associated container.
in each associated container. The container network The container network interface is configurable in
interface is configurable in ``openstack_user_config.yml``. ``openstack_user_config.yml``.
- OpenStack Networking tunnel ``br-vxlan``: - OpenStack Networking tunnel ``br-vxlan``:
@@ -116,10 +113,9 @@ Target hosts contain the following network bridges:
- Provides infrastructure for VXLAN tunnel networks. - Provides infrastructure for VXLAN tunnel networks.
- Manually creates and attaches to a physical or logical interface, - Attaches to a physical or logical interface, typically a ``bond1`` VLAN
typically a ``bond1`` VLAN subinterface. Also attaches to subinterface. Also attaches to ``eth10`` in each associated container.
``eth10`` in each associated container. The The container network interface is configurable in
container network interface is configurable in
``openstack_user_config.yml``. ``openstack_user_config.yml``.
- OpenStack Networking provider ``br-vlan``: - OpenStack Networking provider ``br-vlan``:
@@ -128,11 +124,10 @@ Target hosts contain the following network bridges:
- Provides infrastructure for VLAN networks. - Provides infrastructure for VLAN networks.
- Manually creates and attaches to a physical or logical interface, - Attaches to a physical or logical interface, typically ``bond1``.
typically ``bond1``. Attaches to ``eth11`` for vlan type networks Attaches to ``eth11`` for vlan type networks in each associated
in each associated container. It does not contain an IP address because container. It is not assigned an IP address because it only handles
it only handles layer 2 connectivity. The layer 2 connectivity. The container network interface is configurable in
container network interface is configurable in
``openstack_user_config.yml``. ``openstack_user_config.yml``.
- This interface supports flat networks with additional - This interface supports flat networks with additional

51
doc/source/install-guide-revised-draft/overview-osa.rst
View File

@@ -1,24 +1,14 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
======================= =======================
About OpenStack-Ansible About OpenStack-Ansible
======================= =======================
OpenStack-Ansible (OSA) uses the Ansible IT automation engine to OpenStack-Ansible (OSA) uses the `Ansible IT <https://www.ansible.com/how-ansible-works>`_
deploy an OpenStack environment on Ubuntu Linux. OpenStack components may automation engine to deploy an OpenStack environment on Ubuntu Linux.
be installed into Linux Containers (LXC) for isolation and ease of For isolation and ease of maintenance, you can install OpenStack components
maintenance. into Linux containers (LXC).
This documentation is intended for deployers, and walks through an This documentation is intended for deployers, and walks through an
OpenStack-Ansible installation for a test environment, and a production OpenStack-Ansible installation for a test and production environments.
environment.
Third-party trademarks and tradenames appearing in this document are the
property of their respective owners. Such third-party trademarks have
been printed in caps or initial caps and are used for referential
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.
Ansible Ansible
~~~~~~~ ~~~~~~~
@@ -31,34 +21,33 @@ Ansible uses playbooks written in the YAML language for orchestration.
For more information, see `Ansible - Intro to 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 In this guide, we refer to two types of hosts:
the deployment host and the hosts on which Ansible installs OpenStack services
and infrastructure components as the target hosts.
Linux Containers (LXC) * The host running Ansible playbooks is the `deployment host`.
* The hosts where Ansible installs OpenStack services and infrastructure
components are the `target host`.
Linux containers (LXC)
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
Containers provide operating-system level virtualization by enhancing Containers provide operating-system level virtualization by enhancing
the concept of ``chroot`` environments, which isolate resources and file the concept of ``chroot`` environments. These isolate resources and file
systems for a particular group of processes without the overhead and systems for a particular group of processes without the overhead and
complexity of virtual machines. They access the same kernel, devices, complexity of virtual machines. They access the same kernel, devices,
and file systems on the underlying host and provide a thin operational and file systems on the underlying host and provide a thin operational
layer built around a set of rules. layer built around a set of rules.
The Linux Containers (LXC) project implements operating system level The LXC project implements operating system level
virtualization on Linux using kernel namespaces and includes the virtualization on Linux using kernel namespaces and includes the
following features: following features:
- Resource isolation including CPU, memory, block I/O, and network * Resource isolation including CPU, memory, block I/O, and network
using ``cgroups``. using ``cgroups``.
* Selective connectivity to physical and virtual network devices on the
- Selective connectivity to physical and virtual network devices on the underlying physical host.
underlying physical host. * Support for a variety of backing stores including LVM.
* Built on a foundation of stable Linux technologies with an active
- Support for a variety of backing stores including LVM. development and support community.
- Built on a foundation of stable Linux technologies with an active
development and support community.
-------------- --------------

10
doc/source/install-guide-revised-draft/overview-requirements.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
========================= =========================
Installation requirements Installation requirements
========================= =========================
@@ -57,14 +55,14 @@ Logging hosts
An OpenStack-Ansible deployment generates a significant amount of logging. An OpenStack-Ansible deployment generates a significant amount of logging.
Logs come from a variety of sources, including services running in Logs come from a variety of sources, including services running in
containers, the containers themselves, and the physical hosts. Logging hosts containers, the containers themselves, and the physical hosts. Logging hosts
need additional disk space to hold live and rotated (historical) log files. need sufficient disk space to hold live, and rotated (historical), log files.
In addition, the storage performance must be enough to keep pace with the In addition, the storage performance must be enough to keep pace with the
log traffic coming from various hosts and containers within the OpenStack log traffic coming from various hosts and containers within the OpenStack
environment. Reserve a minimum of 50GB of disk space for storing environment. Reserve a minimum of 50GB of disk space for storing
logs on the logging hosts. logs on the logging hosts.
Hosts that provide Block Storage volumes must have logical volume Hosts that provide Block Storage volumes must have logical volume
manager (LVM) support. Ensure those hosts have a ``cinder-volumes`` volume manager (LVM) support. Ensure those hosts have a ``cinder-volume`` volume
group that OpenStack-Ansible can configure for use with cinder. group that OpenStack-Ansible can configure for use with cinder.
Each control plane host runs services inside LXC containers. The container Each control plane host runs services inside LXC containers. The container
@@ -108,8 +106,8 @@ minimum requirements:
* Ubuntu 14.04 LTS (Trusty Tahr) * Ubuntu 14.04 LTS (Trusty Tahr)
* OSA is tested regularly against the latest Ubuntu 14.04 LTS point * OSA is tested regularly against the latest Ubuntu 14.04 LTS point
releases releases.
* Linux kernel version ``3.13.0-34-generic`` or later * Linux kernel version ``3.13.0-34-generic`` or later.
* For swift storage hosts, you must enable the ``trusty-backports`` * For swift storage hosts, you must enable the ``trusty-backports``
repositories in ``/etc/apt/sources.list`` or ``/etc/apt/sources.list.d/`` repositories in ``/etc/apt/sources.list`` or ``/etc/apt/sources.list.d/``
See the `Ubuntu documentation See the `Ubuntu documentation

58
doc/source/install-guide-revised-draft/overview-storage-arch.rst
View File

@@ -1,11 +1,9 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
==================== ====================
Storage architecture Storage architecture
==================== ====================
OpenStack-Ansible supports Block Storage (cinder), Ephemeral storage OpenStack-Ansible supports Block Storage (cinder), Ephemeral storage
(nova), Image service (glance) and Object Storage (swift). (nova), Image service (glance), and Object Storage (swift).
Block Storage (cinder) Block Storage (cinder)
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
@@ -13,21 +11,21 @@ Block Storage (cinder)
.. important:: .. important::
The Block Storage used by each service is typically on a storage system, not The Block Storage used by each service is typically on a storage system, not
a server. An exception to this is the LVM-backed storage store which is a a server. An exception to this is the LVM-backed storage store; however, this is a
reference implementation and is used primarily for test environments but not reference implementation and is used primarily for test environments and not
for production environments. For non-server storage systems, the cinder-volume for production environments. For non-server storage systems, the ``cinder-volume``
service interacts with the Block Storage system through an API which service interacts with the Block Storage system through an API which
is implemented in the appropriate driver. is implemented in the appropriate driver.
When using the cinder LVM driver, you have separate physical hosts with the When using the cinder LVM driver, you have separate physical hosts with the
volume groups that cinder volumes will use. volume groups that cinder volumes will use.
Most of the other external cinder storage (For example: Ceph, EMC, NAS, and Most of the other external cinder storage (For example: Ceph, EMC, NAS, and
NFS) set up a container inside one of the infra hosts. NFS) sets up a container inside one of the infra hosts.
.. note:: .. note::
The ``cinder_volumes`` service cannot run in a highly available configuration. The ``cinder-volume`` service cannot run in a highly available configuration.
This is not to be set up on multiple hosts. If you have multiple storage Do not set it up on multiple hosts. If you have multiple storage
backends, set up one per volumes container. backends, set up one per volumes container.
For more information: `<https://specs.openstack.org/openstack/cinder-specs/specs/mitaka/cinder-volume-active-active-support.html>`_. For more information: `<https://specs.openstack.org/openstack/cinder-specs/specs/mitaka/cinder-volume-active-active-support.html>`_.
@@ -43,35 +41,36 @@ Configure ``cinder-volumes`` hosts with ``br-storage`` and ``br-mgmt``.
.. note:: .. note::
It is recommended for production environment that the traffic (storage and For production environments segregate the traffic (storage and
API request) from the hosts be segregated onto its own network. API request) from the hosts onto dedicated networks.
Object Storage (swift) Object Storage (swift)
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
The swift proxy service container resides on one of the infra hosts whereas the The Object Storage proxy service container resides on one of the infra hosts
actual swift objects are stored on separate physical hosts. whereas the actual swift objects are stored on separate physical hosts.
.. important:: .. important::
The swift proxy service is responsible for storage, retrieval, encoding and The swift proxy service is responsible for storage, retrieval, encoding, and
decoding of objects from an object server. decoding of objects from an object server.
Configuring the Object Storage Configuring the Object Storage service
------------------------------ --------------------------------------
Ensure the swift proxy hosts are configured with ``br-mgmt`` and Ensure the swift proxy hosts are configured with ``br-mgmt`` and ``br-
``br-storage``. Ensure storage hosts are on ``br-storage``. When using storage``. Ensure storage hosts are configured with ``br-storage``. When using
dedicated replication, also ensure storage hosts are on ``br-repl``. dedicated replication, also ensure storage hosts are configured with ``br-
repl``.
``br-storage`` handles the retrieval and upload of objects to the storage ``br-storage`` handles the retrieval and upload of objects to the storage
nodes. ``br-mgmt`` handles the API requests. nodes. ``br-mgmt`` handles the API requests.
* ``br-storage`` handles the transfer of objects from the storage hosts to * ``br-storage`` carries traffic for the transfer of objects from the storage
the proxy and vice-versa. hosts to the proxy and vice-versa.
* ``br-repl`` handles the replication of objects between storage hosts, * ``br-repl`` carries traffic for the replication of objects between storage
and is not needed by the proxy containers. hosts, and is not needed by the proxy containers.
.. note:: .. note::
@@ -85,18 +84,18 @@ Ephemeral storage (nova)
The ``nova-scheduler`` container resides on the infra host. The The ``nova-scheduler`` container resides on the infra host. The
``nova-scheduler`` service determines on which host (node on ``nova-scheduler`` service determines on which host (node on
which ``nova-compute`` service is running) a particular VM which ``nova-compute`` service is running) a particular VM
should launch. launches.
The ``nova-api-os-compute`` container resides on the infra host. The The ``nova-api-os-compute`` container resides on the infra host. The
``nova-compute`` service resides on the compute host. The ``nova-compute`` service resides on the compute host. The
``nova-api-os-compute`` container handles the client API requests and ``nova-api-os-compute`` container handles the client API requests and
passes messages to the ``nova-scheduler``. The API requests may passes messages to the ``nova-scheduler``. The API requests may
involve operations that requires scheduling (For example: instance involve operations that require scheduling (For example, instance
creation or deletion). These messages are then sent to creation or deletion). These messages are then sent to
``nova-conductor`` which in turn pushes messages to ``nova-compute`` ``nova-conductor`` which in turn pushes messages to ``nova-compute``
on the compute host. on the compute host.
Configuring the ephemeral storage Configuring the Ephemeral storage
--------------------------------- ---------------------------------
All nova containers on the infra hosts communicate using the AMQP service over All nova containers on the infra hosts communicate using the AMQP service over
@@ -113,9 +112,8 @@ carry traffic to the storage host. Configure the
.. note:: .. note::
It is recommended for production environment that the traffic (storage For production environments segregate the traffic (storage and
and API request) from the hosts be segregated onto its own network. API request) from the hosts onto dedicated networks.
Image service (glance) Image service (glance)
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
@@ -125,7 +123,7 @@ infra hosts.
Configuring the Image service Configuring the Image service
----------------------------- -----------------------------
Configure glance-volume container to use the ``br-storage`` and Configure the ``glance-volume`` container to use the ``br-storage`` and
``br-mgmt`` interfaces. ``br-mgmt`` interfaces.
* ``br-storage`` bridge carries image traffic to compute host. * ``br-storage`` bridge carries image traffic to compute host.

7
doc/source/install-guide-revised-draft/overview-workflow.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
===================== =====================
Installation workflow Installation workflow
===================== =====================
@@ -16,10 +14,9 @@ OpenStack-Ansible installation.
#. :doc:`Prepare deployment host <deploymenthost>` #. :doc:`Prepare deployment host <deploymenthost>`
#. :doc:`Prepare target hosts <targethosts>` #. :doc:`Prepare target hosts <targethosts>`
#. :doc:`Configure deployment <configure>` #. :doc:`Configure deployment <configure>`
#. :doc:`Run playbooks <installation>` #. :doc:`Run playbooks <installation#run-playbooks>`
#. :doc:`Verify OpenStack operation <installation>` #. :doc:`Verify OpenStack operation <installation>`
======= -----------
.. include:: navigation.txt .. include:: navigation.txt

105
doc/source/install-guide-revised-draft/targethosts-networkconfig.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
===================== =====================
Network configuration Network configuration
===================== =====================
@@ -35,39 +33,39 @@ bridges that are to be configured on hosts.
Example for 3 controller nodes and 2 compute nodes Example for 3 controller nodes and 2 compute nodes
-------------------------------------------------- --------------------------------------------------
- VLANs: * VLANs:
- Host management: Untagged/Native * Host management: Untagged/Native
- Container management: 10 * Container management: 10
- Tunnels: 30 * Tunnels: 30
- Storage: 20 * Storage: 20
- Networks: * Networks:
- Host management: 10.240.0.0/22 * Host management: 10.240.0.0/22
- Container management: 172.29.236.0/22 * Container management: 172.29.236.0/22
- Tunnel: 172.29.240.0/22 * Tunnel: 172.29.240.0/22
- Storage: 172.29.244.0/22 * Storage: 172.29.244.0/22
- Addresses for the controller nodes: * Addresses for the controller nodes:
- Host management: 10.240.0.11 - 10.240.0.13 * Host management: 10.240.0.11 - 10.240.0.13
- Host management gateway: 10.240.0.1 * Host management gateway: 10.240.0.1
- DNS servers: 69.20.0.164 69.20.0.196 * DNS servers: 69.20.0.164 69.20.0.196
- Container management: 172.29.236.11 - 172.29.236.13 * Container management: 172.29.236.11 - 172.29.236.13
- Tunnel: no IP (because IP exist in the containers, when the components * Tunnel: no IP (because IP exist in the containers, when the components
aren't deployed directly on metal) are not deployed directly on metal)
- Storage: no IP (because IP exist in the containers, when the components * Storage: no IP (because IP exist in the containers, when the components
aren't deployed directly on metal) are not deployed directly on metal)
- Addresses for the compute nodes: * Addresses for the compute nodes:
- Host management: 10.240.0.21 - 10.240.0.22 * Host management: 10.240.0.21 - 10.240.0.22
- Host management gateway: 10.240.0.1 * Host management gateway: 10.240.0.1
- DNS servers: 69.20.0.164 69.20.0.196 * DNS servers: 69.20.0.164 69.20.0.196
- Container management: 172.29.236.21 - 172.29.236.22 * Container management: 172.29.236.21 - 172.29.236.22
- Tunnel: 172.29.240.21 - 172.29.240.22 * Tunnel: 172.29.240.21 - 172.29.240.22
- Storage: 172.29.244.21 - 172.29.244.22 * Storage: 172.29.244.21 - 172.29.244.22
.. TODO Update this section. Should this information be moved to the overview .. TODO Update this section. Should this information be moved to the overview
@@ -83,7 +81,7 @@ on the production environment described in `host layout for production
environment`_. environment`_.
.. _host layout for production environment: overview-host-layout.html#production-environment .. _host layout for production environment: overview-host-layout.html#production-environment
.. _Link to Production Environment: targethosts-networkexample.html#production-environment .. _Link to Production Environment: app-targethosts-networkexample.html#production-environment
Test environment Test environment
~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~
@@ -92,39 +90,28 @@ This example uses the following parameters to configure networking on a
single target host. See `Figure 3.2`_ for a visual representation of these single target host. See `Figure 3.2`_ for a visual representation of these
parameters in the architecture. parameters in the architecture.
- VLANs: * VLANs:
- Host management: Untagged/Native * Host management: Untagged/Native
* Container management: 10
* Tunnels: 30
* Storage: 20
- Container management: 10 * Networks:
- Tunnels: 30 * Host management: 10.240.0.0/22
* Container management: 172.29.236.0/22
* Tunnel: 172.29.240.0/22
* Storage: 172.29.244.0/22
- Storage: 20 * Addresses:
Networks: * Host management: 10.240.0.11
* Host management gateway: 10.240.0.1
- Host management: 10.240.0.0/22 * DNS servers: 69.20.0.164 69.20.0.196
* Container management: 172.29.236.11
- Container management: 172.29.236.0/22 * Tunnel: 172.29.240.11
* Storage: 172.29.244.11
- Tunnel: 172.29.240.0/22
- Storage: 172.29.244.0/22
Addresses:
- Host management: 10.240.0.11
- Host management gateway: 10.240.0.1
- DNS servers: 69.20.0.164 69.20.0.196
- Container management: 172.29.236.11
- Tunnel: 172.29.240.11
- Storage: 172.29.244.11
.. _Figure 3.2: targethosts-networkconfig.html#fig_hosts-target-network-containerexample .. _Figure 3.2: targethosts-networkconfig.html#fig_hosts-target-network-containerexample
@@ -138,11 +125,11 @@ Modifying the network interfaces file
After establishing initial host management network connectivity using After establishing initial host management network connectivity using
the ``bond0`` interface, modify the ``/etc/network/interfaces`` file. the ``bond0`` interface, modify the ``/etc/network/interfaces`` file.
An example is provided below on this `Link to Test Environment`_ based An example is provided below on this `link to Test Environment`_ based
on the test environment described in `host layout for testing on the test environment described in `host layout for testing
environment`_. environment`_.
.. _Link to Test Environment: targethosts-networkexample.html#test-environment .. _Link to Test Environment: app-targethosts-networkexample.html#test-environment
.. _host layout for testing environment: overview-host-layout.html#test-environment .. _host layout for testing environment: overview-host-layout.html#test-environment

20
doc/source/install-guide-revised-draft/targethosts-prepare.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
========================== ==========================
Preparing the target hosts Preparing the target hosts
========================== ==========================
@@ -17,8 +15,10 @@ to access the internet or suitable local repositories.
We recommend adding the Secure Shell (SSH) server packages to the We recommend adding the Secure Shell (SSH) server packages to the
installation on target hosts without local (console) access. installation on target hosts without local (console) access.
We also recommend setting your locale to en_US.UTF-8. Other locales may .. note::
work, but they are not tested or supported.
We also recommend setting your locale to `en_US.UTF-8`. Other locales may
work, but they are not tested or supported.
Configuring the operating system Configuring the operating system
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -50,8 +50,8 @@ Configuring the operating system
#. Reboot the host to activate the changes and use new kernel. #. Reboot the host to activate the changes and use new kernel.
Deploying SSH keys Deploying Secure Shell (SSH) keys
~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ansible uses SSH for connectivity between the deployment and target hosts. Ansible uses SSH for connectivity between the deployment and target hosts.
@@ -78,10 +78,8 @@ practices, refer to `GitHub's documentation on generating SSH keys`_.
``lxc_container_ssh_key`` variable to the public key for ``lxc_container_ssh_key`` variable to the public key for
the container. the container.
Configuring LVM Configuring storage
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~
.. TODO Change title to Configuring Storage and add content
`Logical Volume Manager (LVM)`_ allows a single device to be split into `Logical Volume Manager (LVM)`_ allows a single device to be split into
multiple logical volumes which appear as a physical storage device to the multiple logical volumes which appear as a physical storage device to the
@@ -96,7 +94,7 @@ their data storage.
configuration, edit the generated configuration file as needed. configuration, edit the generated configuration file as needed.
#. To use the optional Block Storage (cinder) service, create an LVM #. To use the optional Block Storage (cinder) service, create an LVM
volume group named ``cinder-volumes`` on the Block Storage host. A volume group named ``cinder-volume`` on the Block Storage host. A
metadata size of 2048 must be specified during physical volume metadata size of 2048 must be specified during physical volume
creation. For example: creation. For example:

23
doc/source/install-guide-revised-draft/targethosts.rst
View File

@@ -1,5 +1,3 @@
`Home <index.html>`_ OpenStack-Ansible Installation Guide
============ ============
Target hosts Target hosts
============ ============
@@ -7,27 +5,20 @@ Target hosts
.. figure:: figures/installation-workflow-targethosts.png .. figure:: figures/installation-workflow-targethosts.png
:width: 100% :width: 100%
**Installation workflow**
.. toctree:: .. toctree::
:maxdepth: 2
targethosts-prepare.rst targethosts-prepare.rst
targethosts-networkconfig.rst targethosts-networkconfig.rst
On each target host, perform the following tasks: On each target host, perform the following tasks:
- Name the target hosts * Name the target hosts
* Install the operating system
- Install the operating system * Generate and set up security measures
* Update the operating system and install additional software packages
- Generate and set up security measures * Create LVM volume groups
* Configure networking devices
- Update the operating system and install additional software packages
- Create LVM volume groups
- Configure networking devices
-------------- --------------