diff --git a/0020-about-fuel.rst b/0020-about-fuel.rst
index b41e58ea3..4e9080049 100644
--- a/0020-about-fuel.rst
+++ b/0020-about-fuel.rst
@@ -4,11 +4,12 @@
About Fuel
============
-.. _contents:: :local:
+.. contents:: :local:
+ :depth: 2
.. include /pages/about-fuel/0010-introduction.rst
.. include:: /pages/about-fuel/0020-what-is-fuel.rst
.. include:: /pages/about-fuel/0030-how-it-works.rst
.. include:: /pages/about-fuel/0040-reference-topologies.rst
.. include:: /pages/about-fuel/0050-supported-software.rst
-.. include:: /pages/about-fuel/0060-download-fuel.rst
\ No newline at end of file
+.. include:: /pages/about-fuel/0060-download-fuel.rst
diff --git a/0030-release-notes.rst b/0030-release-notes.rst
index f8756a3f7..d9196153e 100644
--- a/0030-release-notes.rst
+++ b/0030-release-notes.rst
@@ -5,6 +5,9 @@
=============
Release Notes
=============
+..
+ contents:: :local:
+ :depth: 1
.. include:: /pages/release-notes/v3-1-grizzly.rst
.. include /pages/release-notes/v3-0-grizzly.rst
diff --git a/0040-reference-architecture.rst b/0040-reference-architecture.rst
index ee5b8428d..f07e402fe 100644
--- a/0040-reference-architecture.rst
+++ b/0040-reference-architecture.rst
@@ -6,9 +6,15 @@
Reference Architectures
=======================
+.. contents:: :local:
+ :depth: 2
+
.. include:: /pages/reference-architecture/0010-overview.rst
+.. include:: /pages/reference-architecture/0012-simple.rst
+.. include:: /pages/reference-architecture/0014-compact.rst
+.. include:: /pages/reference-architecture/0016-full.rst
.. include:: /pages/reference-architecture/0015-closer-look.rst
-.. include:: /pages/reference-architecture/0016-red-hat-differences.rst
+.. include:: /pages/reference-architecture/0018-red-hat-differences.rst
.. include:: /pages/reference-architecture/0020-logical-setup.rst
.. include:: /pages/reference-architecture/0030-cluster-sizing.rst
.. include:: /pages/reference-architecture/0040-network-setup.rst
@@ -16,4 +22,4 @@ Reference Architectures
.. include:: /pages/reference-architecture/0060-quantum-vs-nova-network.rst
.. include:: /pages/reference-architecture/0070-cinder-vs-nova-volume.rst
.. include:: /pages/reference-architecture/0080-swift-notes.rst
-
+.. include:: /pages/reference-architecture/0090-ha-notes.rst
diff --git a/0045-installation-fuel-ui.rst b/0045-installation-fuel-ui.rst
index 2bc5c4f13..76808a965 100644
--- a/0045-installation-fuel-ui.rst
+++ b/0045-installation-fuel-ui.rst
@@ -6,6 +6,9 @@
Create an OpenStack cluster using Fuel UI
============================================
+.. contents:: :local:
+ :depth: 2
+
.. include:: /pages/installation-fuel-ui/install.rst
.. include:: /pages/installation-fuel-ui/networks.rst
.. include:: /pages/installation-fuel-ui/network-issues.rst
diff --git a/0050-installation-fuel-cli.rst b/0050-installation-fuel-cli.rst
index c4a41aa47..c589c3fcc 100644
--- a/0050-installation-fuel-cli.rst
+++ b/0050-installation-fuel-cli.rst
@@ -6,7 +6,8 @@
Deploy an OpenStack cluster using Fuel CLI
==========================================
-.. contents: :local:
+.. contents:: :local:
+ :depth: 2
.. include: /pages/installation-fuel-cli/0000-preamble.rst
.. include: /pages/installation-fuel-cli/0010-introduction.rst
diff --git a/0055-production-considerations.rst b/0055-production-considerations.rst
index 76dc4b516..6faea0420 100644
--- a/0055-production-considerations.rst
+++ b/0055-production-considerations.rst
@@ -6,7 +6,19 @@
Production Considerations
=========================
-.. include:: /pages/production-considerations/0010-introduction.rst
+Fuel simplifies the set up of an OpenStack cluster, affording you the ability
+to dig in and fully understand how OpenStack works. You can deploy on test
+hardware or in a virtualized environment and root around all you like, but
+when it comes time to deploy to production there are a few things to take
+into consideration.
+
+In this section we will talk about such things including how to size your
+hardware and how to handle large-scale deployments.
+
+.. contents:: :local:
+ :depth: 2
+
+.. include /pages/production-considerations/0010-introduction.rst
.. include:: /pages/production-considerations/0015-sizing-hardware.rst
.. include:: /pages/production-considerations/0020-deployment-pipeline.rst
.. include:: /pages/production-considerations/0030-large-deployments.rst
diff --git a/0060-frequently-asked-questions.rst b/0060-frequently-asked-questions.rst
index 8fdba895e..8eca15877 100644
--- a/0060-frequently-asked-questions.rst
+++ b/0060-frequently-asked-questions.rst
@@ -6,7 +6,8 @@
FAQ (Frequently Asked Questions)
================================
-.. _contents:: :local:
+.. contents:: :local:
+ :depth: 2
.. Known Issues and Workarounds
diff --git a/Makefile b/Makefile
index 76aede02c..6fd33c085 100644
--- a/Makefile
+++ b/Makefile
@@ -17,7 +17,7 @@ I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) .
IMAGEDIRS = _images
SVG2JPG = convert
# JPGs will be resized to 600px width
-SVG2JPG_FLAGS = -resize 600x
+SVG2JPG_FLAGS = -resize 600x -quality 100%
.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf pdf text man changes linkcheck doctest gettext
diff --git a/_images/physical-network.jpg b/_images/physical-network.jpg
index 422cfcc92..ba36cd404 100644
Binary files a/_images/physical-network.jpg and b/_images/physical-network.jpg differ
diff --git a/_images/physical-network.png b/_images/physical-network.png
new file mode 100644
index 000000000..50556ae66
Binary files /dev/null and b/_images/physical-network.png differ
diff --git a/_templates/mirantis/layout.html b/_templates/mirantis/layout.html
index ba3605efa..c8b9d65b4 100644
--- a/_templates/mirantis/layout.html
+++ b/_templates/mirantis/layout.html
@@ -77,7 +77,9 @@ var ga_enabled = !$.cookie('disable-ga');
if(ga_enabled){
var _gaq = _gaq || [];
_gaq.push(['_setAccount', '{{ theme_googleanalytics_id }}']);
+
_gaq.push(['_setCookiePath', '{{ theme_googleanalytics_path }}']);
+ _gaq.push(['_setDomainName', 'mirantis.com']);
_gaq.push(['_setDetectFlash', false]);
_gaq.push(['_trackPageview']);
(function() {
diff --git a/_templates/mirantis/static/mirantis.css_t b/_templates/mirantis/static/mirantis.css_t
index 72368728a..b4d8423f6 100644
--- a/_templates/mirantis/static/mirantis.css_t
+++ b/_templates/mirantis/static/mirantis.css_t
@@ -13,11 +13,16 @@
@import url("mirantis_style.css");
+.highlight .hll {
+ background-color: #C0FF7C !important;
+}
+
+
div.highlight pre,
div.highlight-python pre
{
border-width: 0px 3px;
-
+ background-color: #F7FFE8;
border-radius: 6px;
-moz-border-radius: 6px;
-webkit-border-radius: 6px;
diff --git a/_templates/mirantis/static/mirantis_style.css b/_templates/mirantis/static/mirantis_style.css
index 78c275b60..556de261e 100644
--- a/_templates/mirantis/static/mirantis_style.css
+++ b/_templates/mirantis/static/mirantis_style.css
@@ -3,8 +3,14 @@ li.toctree-l1, li.toctree-l2
margin-top: 4px;
}
+div.disqus_thread
+{
+ padding: 10px;
+}
+
div.relbar-bottom div.related_hf
{
+ background: #FFFFFF;
border-radius: 0 0 .7em .7em;
-moz-border-radius: 0 0 .7em .7em;
-webkit-border-radius: 0 0 .7em .7em;
diff --git a/conf.py b/conf.py
index 5e45b5227..298a425e7 100644
--- a/conf.py
+++ b/conf.py
@@ -75,7 +75,8 @@ release = '3.1'
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
-exclude_patterns = ['_*', "pages"]
+exclude_patterns = ['_*', "pages", 'rn_index.rst']
+# exclude_patterns = ['_*', 'rn_index.rst']
# The reST default role (used for this markup: `text`) to use for all documents.
#default_role = None
@@ -142,7 +143,7 @@ html_static_path = ['_static']
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
-html_use_smartypants = True
+html_use_smartypants = False
# Custom sidebar templates, maps document names to template names.
html_sidebars = {
@@ -160,7 +161,7 @@ html_sidebars = {
html_use_index = True
# If true, the index is split into individual pages for each letter.
-html_split_index = True
+html_split_index = False
# If true, links to the reST sources are added to the pages.
html_show_sourcelink = False
@@ -293,18 +294,18 @@ pdf_fit_mode = "shrink"
# Section level that forces a break page.
# For example: 1 means top-level sections start in a new page
# 0 means disabled
-#pdf_break_level = 0
+pdf_break_level = 2
# When a section starts in a new page, force it to be 'even', 'odd',
# or just use 'any'
-#pdf_breakside = 'any'
+pdf_breakside = 'any'
# Insert footnotes where they are defined instead of
# at the end.
#pdf_inline_footnotes = True
# verbosity level. 0 1 or 2
-pdf_verbosity = 2
+pdf_verbosity = 0
# If false, no index is generated.
#pdf_use_index = True
@@ -337,7 +338,7 @@ pdf_cover_template = 'mirantiscover.tmpl'
pdf_page_template = 'oneColumn'
# Show Table Of Contents at the beginning?
-pdf_use_toc = False
+pdf_use_toc = True
# How many levels deep should the table of contents be?
pdf_toc_depth = 2
diff --git a/contents.rst b/contents.rst
index 2016a1dff..f242eece7 100644
--- a/contents.rst
+++ b/contents.rst
@@ -1,20 +1,16 @@
-.. index:: Table of Contents
+.. index Table of Contents
.. _ToC:
-=================
-Table of Contents
-=================
+.. toctree:: Table of Contents
+ :maxdepth: 2
-.. toctree::
- :maxdepth: 2
-
- index
- 0020-about-fuel
- 0030-release-notes
- 0040-reference-architecture
- 0055-production-considerations
- 0045-installation-fuel-ui
- 0050-installation-fuel-cli
- 0060-frequently-asked-questions
- copyright
+ index
+ 0020-about-fuel
+ 0030-release-notes
+ 0040-reference-architecture
+ 0055-production-considerations
+ 0045-installation-fuel-ui
+ 0050-installation-fuel-cli
+ 0060-frequently-asked-questions
+ copyright
diff --git a/0058-advanced-configuration.rst b/pages/0058-advanced-configuration.rst
similarity index 100%
rename from 0058-advanced-configuration.rst
rename to pages/0058-advanced-configuration.rst
diff --git a/pages/about-fuel/0020-what-is-fuel.rst b/pages/about-fuel/0020-what-is-fuel.rst
index b8a586d09..7c1ef5e6b 100644
--- a/pages/about-fuel/0020-what-is-fuel.rst
+++ b/pages/about-fuel/0020-what-is-fuel.rst
@@ -1,4 +1,4 @@
-.. index:: What is Fuel?
+.. index:: What is Fuel
.. _What_is_Fuel:
@@ -21,4 +21,4 @@ Simply put, Fuel is a way for you to easily configure and install an
OpenStack-based infrastructure in your own environment.
.. image:: /_images/FuelSimpleDiagram.jpg
-
+ :align: center
diff --git a/pages/about-fuel/0030-how-it-works.rst b/pages/about-fuel/0030-how-it-works.rst
index f7ed9776f..f729792df 100644
--- a/pages/about-fuel/0030-how-it-works.rst
+++ b/pages/about-fuel/0030-how-it-works.rst
@@ -12,24 +12,25 @@ configurable, reproducible, sharable installation process.
In practice, that means that the process of using Fuel looks like 1-2-3:
-1. First, set up Fuel Master Node using the ISO. This process only needs to be
+1. First, set up Fuel Master node using the ISO. This process only needs to be
completed once per installation.
-2. Next, discover your virtual or phisical nodes and configure your OpenStack
- cluster using the Fuel UI.
+2. Next, discover your virtual or bare-metal nodes and configure your OpenStack
+ cluster using the Fuel UI or CLI.
3. Finally, deploy your OpenStack cluster on discovered nodes. Fuel will do all
deployment magic for you by applying pre-configured Puppet manifests.
-All of this is desgined to enable you to maintain your cluster while giving
+All of this is designed to enable you to maintain your cluster while giving
you the flexibility to adapt it to your own configuration.
.. image:: /_images/how-it-works_svg.jpg
+ :align: center
Fuel comes with several pre-defined deployment configurations, some of them
include additional configuration options that allow you to adapt OpenStack
deployment to your environment.
Fuel UI integrates all of the deployments scripts into a unified,
-web-based graphical user interface that walks administrators through the
+Web-based Graphical User Interface that walks administrators through the
process of installing and configuring a fully functional OpenStack environment.
diff --git a/pages/about-fuel/0050-supported-software.rst b/pages/about-fuel/0050-supported-software.rst
index 916f52e5f..60f85bb17 100644
--- a/pages/about-fuel/0050-supported-software.rst
+++ b/pages/about-fuel/0050-supported-software.rst
@@ -7,43 +7,53 @@ Fuel has been tested and is guaranteed to work with the following software
components:
* Operating Systems
- * CentOS 6.4 (x86_64 architecture only)
- * RHEL 6.4 (x86_64 architecture only)
+
+ * CentOS 6.4 (x86_64 architecture only)
+
+ * RHEL 6.4 (x86_64 architecture only)
* Puppet (IT automation tool)
- * 2.7.19
+
+ * 2.7.19
* MCollective
- * 2.3.1
+
+ * 2.3.1
* Cobbler (bare-metal provisioning tool)
- * 2.2.3
+
+ * 2.2.3
* OpenStack
- * Grizzly release 2013.1
+
+ * Grizzly release 2013.1.2
* Hypervisor
- * KVM
- * QEMU
+
+ * KVM
+
+ * QEMU
* Open vSwitch
- * 1.10.0
+
+ * 1.10.0
* HA Proxy
- * 1.4.19
+
+ * 1.4.19
* Galera
- * 23.2.2
+
+ * 23.2.2
* RabbitMQ
- * 2.8.7
+
+ * 2.8.7
* Pacemaker
- * 1.1.8
+
+ * 1.1.8
* Corosync
- * 1.4.3
-
-* Nagios
- * 3.4.4
+ * 1.4.3
diff --git a/pages/installation-fuel-cli/0060-understand-the-manifest.rst b/pages/installation-fuel-cli/0060-understand-the-manifest.rst
index 64b543ff7..95098b764 100644
--- a/pages/installation-fuel-cli/0060-understand-the-manifest.rst
+++ b/pages/installation-fuel-cli/0060-understand-the-manifest.rst
@@ -41,7 +41,7 @@ and Astute orchestrator passes to the next node in deployment sequence.
Deploying OpenStack Cluster Using CLI
=====================================
-.. contents:: :local:
+.. contents :local:
After you understood how deployment workflow is traversed, you can finally start.
Connect the nodes to Master node and power them on. You should also plan your
@@ -111,6 +111,9 @@ Sample YAML configuration for provisioning is listed below:
# == id
# MCollective node id in mcollective server.cfg.
- id: 1
+ # == uid
+ # UID of the node for deployment engine. Should be equal to `id`
+ uid: 1
# == mac
# MAC address of the interface being used for network boot.
mac: 64:43:7B:CA:56:DD
@@ -333,7 +336,7 @@ Wait for command to finish. Now you can start configuring OpenStack cluster para
Configuring Nodes for Deployment
================================
-.. contents:: :local:
+.. contents :local:
Node Configuration
------------------
@@ -384,9 +387,6 @@ section of the file with data related to deployment.
# == internal_br
# Name of the internal bridge for Quantum-enabled configuration
internal_br: br-mgmt
- # == id
- # UID of the node for deployment engine. Should be equal to `id`
- uid: 1
General Parameters
------------------
diff --git a/pages/installation-fuel-cli/0070-orchestration.rst b/pages/installation-fuel-cli/0070-orchestration.rst
index 384582d96..b743410c7 100644
--- a/pages/installation-fuel-cli/0070-orchestration.rst
+++ b/pages/installation-fuel-cli/0070-orchestration.rst
@@ -3,7 +3,7 @@
Deploying via Orchestration
===========================
-.. contents:: :local:
+.. contents :local:
Performing a small series of manual installs many be an acceptable approach in
some circumstances, but if you plan on deploying to a large number of servers
diff --git a/pages/installation-fuel-cli/0080-testing-openstack.rst b/pages/installation-fuel-cli/0080-testing-openstack.rst
index 613004cee..f8420305a 100644
--- a/pages/installation-fuel-cli/0080-testing-openstack.rst
+++ b/pages/installation-fuel-cli/0080-testing-openstack.rst
@@ -11,7 +11,7 @@ for a drive around the block. Follow these steps:
2. Click the ``Project`` tab in the left-hand column.
3. Under ``Manage Compute``, choose ``Access & Security`` to set security
-settings:
+ settings:
- Click ``Create Keypair`` and enter a name for the new keypair. The
private key should download automatically; make sure to keep it safe.
@@ -29,7 +29,7 @@ settings:
-1 to the default Security Group and click ``Add Rule`` to save.
4. Click ``Allocate IP To Project`` and add two new floating IPs. Notice that
- they come from the pool specified in ``config.yaml`` and ``site.pp``.
+ they come from the pool specified in ``config.yaml`` and ``site.pp``.
5. Click ``Images & Snapshots``, then ``Create Image``.
diff --git a/pages/installation-fuel-ui/install.rst b/pages/installation-fuel-ui/install.rst
index 243b9d271..138c23e30 100644
--- a/pages/installation-fuel-ui/install.rst
+++ b/pages/installation-fuel-ui/install.rst
@@ -3,7 +3,7 @@
Installing Fuel Master Node
===========================
-.. contents:: :local:
+.. contents :local:
Fuel is distributed as both ISO and IMG images, each of them contains
an installer for Fuel Master node. The ISO image is used for CD media devices,
@@ -67,7 +67,7 @@ simple, single-click installation.
The requirements for running Fuel on VirtualBox are:
A host machine with Linux or Mac OS.
- The scripts have been tested on Mac OS 10.7.5, Mac OS 10.8.3, and Ubuntu 12.04.
+ The scripts have been tested on Mac OS 10.7.5, Mac OS 10.8.3, Ubuntu 12.04 and Ubuntu 12.10.
VirtualBox 4.2.12 (or later) must be installed with the extension pack. Both
can be downloaded from ``_.
@@ -81,7 +81,7 @@ can be downloaded from ``_.
.. _Install_Automatic:
Automatic Mode
-^^^^^^^^^^^^^^
+++++++++++++++
When you unpack the scripts, you will see the following important files and
folders:
@@ -97,16 +97,49 @@ folders:
`launch.sh`
Once executed, this script will pick up an image from the ``iso`` directory,
create a VM, mount the image to this VM, and automatically install the Fuel
- Master Тode.
- After installation of the master node, the script will create slave nodes for
- OpenStack and boot them via PXE from the Master Node.
+ Master node.
+ After installation of the Master node, the script will create Slave nodes for
+ OpenStack and boot them via PXE from the Master node.
Finally, the script will give you the link to access the Web-based UI for the
Master Node so you can start installation of an OpenStack cluster.
+Networking Notes for Slave Nodes
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Helper scripts for VirtualBox create network adapters eth0, eth1, eth2 assigned
+to vboxnet0, vboxnet1, vboxnet2 correspondingly. vboxnet0 is dedicated for Fuel
+network so it is impossible to use it for any other untagged networks.
+
+Also these scripts assign IP addresses for adapters: vboxnet0 - 10.20.0.1/24,
+vboxnet1 - 172.16.1.1/24, vboxnet2 - 172.16.0.1/24.
+
+To access guest VMs from host machine Public and/or Management networks must be
+untagged and assigned to vboxnet1 and vboxnet2 adapters with IP addresses from
+ranges specified earlier.
+
+During installation the Slave nodes access the Internet via Master node.
+But when installation is done Slave nodes on guest VMs shall access the
+Internet via the Public network. To make it happen the following command must be
+executed on host::
+
+ sudo iptables -t nat -A POSTROUTING -s 172.16.1.0/24 \! -d 172.16.1.0/24 -j MASQUERADE
+
+To access VMs managed by OpenStack it is needed to provide IP addresses from
+floating IP range. When OpenStack cluster is deployed it is needed to create
+security groups to provide access to guest VMs using following commands::
+
+ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0
+ nova secgroup-add-rule default tcp 22 22 0.0.0.0/0
+
+You can also add these security groups from Horizon UI.
+
+IP ranges for Public and Management networks (172.16.*.*) defined in `config.sh`
+script. You can reassign these IP ranges before running VirtualBox scripts only.
+
.. _Install_Manual:
Manual mode
-^^^^^^^^^^^
++++++++++++
If you cannot or would rather not run our helper scripts, you can still run
Fuel on VirtualBox by following these steps.
@@ -120,7 +153,7 @@ Fuel on VirtualBox by following these steps.
helper scripts or install Fuel :ref:`Install_Bare-Metal`.
Master Node deployment
-~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^
First, create the Master Node VM.
@@ -144,7 +177,7 @@ First, create the Master Node VM.
of Fuel.
Adding Slave Nodes
-~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^
Next, create Slave nodes where OpenStack needs to be installed.
@@ -158,12 +191,12 @@ Next, create Slave nodes where OpenStack needs to be installed.
2. Set priority for the network boot:
.. image:: /_images/vbox-image1.jpg
- :width: 600px
+ :align: center
3. Configure the network adapter on each VM:
.. image:: /_images/vbox-image2.jpg
- :width: 600px
+ :align: center
Changing network parameters before the installation
---------------------------------------------------
@@ -178,12 +211,13 @@ as the gateway and DNS server you should change the parameters to those shown
in the image below:
.. image:: /_images/network-at-boot.jpg
+ :align: center
When you're finished making changes, press the key and wait for the
installation to complete.
Changing network parameters after installation
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+----------------------------------------------
.. warning::
@@ -234,7 +268,7 @@ Now you should be able to connect to Fuel UI from your network at
http://172.18.0.5:8000/
Name resolution (DNS)
-^^^^^^^^^^^^^^^^^^^^^
+---------------------
During Master Node installation, it is assumed that there is a recursive DNS
service on 10.20.0.1.
@@ -247,7 +281,7 @@ your actual DNS)::
echo "nameserver 172.0.0.1" > /etc/dnsmasq.upstream
PXE booting settings
-^^^^^^^^^^^^^^^^^^^^
+--------------------
By default, `eth0` on Fuel Master node serves PXE requests. If you are planning
to use another interface, then it is required to modify dnsmasq settings (which
@@ -272,7 +306,7 @@ therefore they will not be able to boot. For example, CentOS 6.4 uses gPXE
implementation instead of more advanced iPXE by default.
When Master Node installation is done
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-------------------------------------
Once the Master node is installed, power on all other nodes and log in to the
Fuel UI.
diff --git a/pages/installation-fuel-ui/network-issues.rst b/pages/installation-fuel-ui/network-issues.rst
index 4a7c0c28a..b8f22ad38 100644
--- a/pages/installation-fuel-ui/network-issues.rst
+++ b/pages/installation-fuel-ui/network-issues.rst
@@ -1,3 +1,5 @@
+.. index:: Fuel UI; Network Issues
+
Network Issues
==============
@@ -10,6 +12,7 @@ multiple switches are not configured correctly and do not allow certain
tagged traffic to pass through.
.. image:: /_images/net_verify_failure.jpg
+ :align: center
On VirtualBox
-------------
@@ -29,64 +32,64 @@ Timeout in connection to OpenStack API from client applications
If you use Java, Python or any other code to work with OpenStack API, all
connections should be done over OpenStack public network. To explain why we
-can not use Fuel admin network, let's try to run nova client with debug
+can not use Fuel network, let's try to run nova client with debug
option enabled::
[root@controller-6 ~]# nova --debug list
- REQ: curl -i http://192.168.0.5:5000/v2.0/tokens -X POST -H "Content-Type: appli
+ REQ: curl -i http://192.168.0.2:5000/v2.0/tokens -X POST -H "Content-Type: appli
cation/json" -H "Accept: application/json" -H "User-Agent: python-novaclient" -d
- '{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin", "
- password": "admin"}}}'
+ '{"auth": {"tenantName": "admin", "passwordCredentials": {"username": "admin",
+ "password": "admin"}}}'
- INFO (connectionpool:191) Starting new HTTP connection (1): 192.168.0.5
- DEBUG (connectionpool:283) "POST /v2.0/tokens HTTP/1.1" 200 2695
- RESP: [200] {'date': 'Thu, 06 Jun 2013 09:50:22 GMT', 'content-type': 'applicati
- on/json', 'content-length': '2695', 'vary': 'X-Auth-Token'}
- RESP BODY: {"access": {"token": {"issued_at": "2013-06-06T09:50:21.950681", "exp
- ires": "2013-06-07T09:50:21Z", "id": "d9ab5c927bcb410d9e9ee5bdea3ea020", "tenant
- ": {"description": "admin tenant", "enabled": true, "id": "1a491e1416d041da93daa
- e1dc8af6d07", "name": "admin"}}, "serviceCatalog": [{"endpoints": [{"adminURL":
- "http://192.168.0.5:8774/v2/1a491e1416d041da93daae1dc8af6d07", "region": "Region
- One", "internalURL": "http://192.168.0.5:8774/v2/1a491e1416d041da93daae1dc8af6d0
- 7", "id": "0281b33145d0417a976b8d0e9bab08b8", "publicURL": "http://240.0.1.5:877
- 4/v2/1a491e1416d041da93daae1dc8af6d07"}], "endpoints_links": [], "type": "comput
- e", "name": "nova"}, {"endpoints": [{"adminURL": "http://192.168.0.5:8080", "reg
- ion": "RegionOne", "internalURL": "http://192.168.0.5:8080", "id": "3c8dea92d2e0
- 46c8bf188b2d357425a1", "publicURL": "http://240.0.1.5:8080"}], "endpoints_links"
- : [], "type": "s3", "name": "swift_s3"}, {"endpoints": [{"adminURL": "http://192
- .168.0.5:9292", "region": "RegionOne", "internalURL": "http://192.168.0.5:9292",
- "id": "d9a08cc4f1294e4c8748966363468089", "publicURL": "http://240.0.1.5:9292"}]
- , "endpoints_links": [], "type": "image", "name": "glance"}, {"endpoints": [{"ad
- minURL": "http://192.168.0.5:8776/v1/1a491e1416d041da93daae1dc8af6d07", "region"
- : "RegionOne", "internalURL": "http://192.168.0.5:8776/v1/1a491e1416d041da93daae
- 1dc8af6d07", "id": "7563a55f46584e149b822507811b868c", "publicURL": "http://240.
- 0.1.5:8776/v1/1a491e1416d041da93daae1dc8af6d07"}], "endpoints_links": [], "type"
- : "volume", "name": "cinder"}, {"endpoints": [{"adminURL": "http://192.168.0.5:8
- 773/services/Admin", "region": "RegionOne", "internalURL": "http://192.168.0.5:8
- 773/services/Cloud", "id": "2f5d062c52b24f85a193306809c9600c", "publicURL": "htt
- p://240.0.1.5:8773/services/Cloud"}], "endpoints_links": [], "type": "ec2", "nam
- e": "nova_ec2"}, {"endpoints": [{"adminURL": "http://192.168.0.5:8080/", "region
- ": "RegionOne", "internalURL": "http://192.168.0.5:8080/v1/AUTH_1a491e1416d041da
- 93daae1dc8af6d07", "id": "2bb237d0db004cd08f1be57fd14e2892", "publicURL": "http:
- //240.0.1.5:8080/v1/AUTH_1a491e1416d041da93daae1dc8af6d07"}], "endpoints_links":
- [], "type": "object-store", "name": "swift"}, {"endpoints": [{"adminURL": "http:
- //192.168.0.5:35357/v2.0", "region": "RegionOne", "internalURL": "http://192.168
- .0.5:5000/v2.0", "id": "2fa7c6deb7ad42aabab7935bc269bb4e", "publicURL": "http://
- 240.0.1.5:5000/v2.0"}], "endpoints_links": [], "type": "identity", "name": "keys
- tone"}], "user": {"username": "admin", "roles_links": [], "id": "d9321ac604694ff
- b9e4a8517292f55d6", "roles": [{"name": "admin"}], "name": "admin"}, "metadata":
- {"is_admin": 0, "roles": ["c80a3ab61b2c42b4bcacb4b316856618"]}}}
+ INFO (connectionpool:191) Starting new HTTP connection (1): 192.168.0.2
+ DEBUG (connectionpool:283) "POST /v2.0/tokens HTTP/1.1" 200 2702
+ RESP: [200] {'date': 'Tue, 06 Aug 2013 13:01:05 GMT', 'content-type': 'applicati
+ on/json', 'content-length': '2702', 'vary': 'X-Auth-Token'}
+ RESP BODY: {"access": {"token": {"issued_at": "2013-08-06T13:01:05.616481", "exp
+ ires": "2013-08-07T13:01:05Z", "id": "c321cd823c8a4852aea4b870a03c8f72", "tenant
+ ": {"description": "admin tenant", "enabled": true, "id": "8eee400f7a8a4f35b7a92
+ bc6cb54de42", "name": "admin"}}, "serviceCatalog": [{"endpoints": [{"adminURL":
+ "http://192.168.0.2:8774/v2/8eee400f7a8a4f35b7a92bc6cb54de42", "region": "Region
+ One", "internalURL": "http://192.168.0.2:8774/v2/8eee400f7a8a4f35b7a92bc6cb54de4
+ 2", "id": "6b9563c1e37542519e4fc601b994f980", "publicURL": "http://172.16.1.2:87
+ 74/v2/8eee400f7a8a4f35b7a92bc6cb54de42"}], "endpoints_links": [], "type": "compu
+ te", "name": "nova"}, {"endpoints": [{"adminURL": "http://192.168.0.2:8080", "re
+ gion": "RegionOne", "internalURL": "http://192.168.0.2:8080", "id": "4db0e11de35
+ 74c889179f499f1e53c7e", "publicURL": "http://172.16.1.2:8080"}], "endpoints_link
+ s": [], "type": "s3", "name": "swift_s3"}, {"endpoints": [{"adminURL": "http://1
+ 92.168.0.2:9292", "region": "RegionOne", "internalURL": "http://192.168.0.2:9292
+ ", "id": "960a3ad83e4043bbbc708733571d433b", "publicURL": "http://172.16.1.2:929
+ 2"}], "endpoints_links": [], "type": "image", "name": "glance"}, {"endpoints": [
+ {"adminURL": "http://192.168.0.2:8776/v1/8eee400f7a8a4f35b7a92bc6cb54de42", "reg
+ ion": "RegionOne", "internalURL": "http://192.168.0.2:8776/v1/8eee400f7a8a4f35b7
+ a92bc6cb54de42", "id": "055edb2aface49c28576347a8c2a5e35", "publicURL": "http://
+ 172.16.1.2:8776/v1/8eee400f7a8a4f35b7a92bc6cb54de42"}], "endpoints_links": [], "
+ type": "volume", "name": "cinder"}, {"endpoints": [{"adminURL": "http://192.168.
+ 0.2:8773/services/Admin", "region": "RegionOne", "internalURL": "http://192.168.
+ 0.2:8773/services/Cloud", "id": "1e5e51a640f94e60aed0a5296eebdb51", "publicURL":
+ "http://172.16.1.2:8773/services/Cloud"}], "endpoints_links": [], "type": "ec2"
+ , "name": "nova_ec2"}, {"endpoints": [{"adminURL": "http://192.168.0.2:8080/",
+ "region": "RegionOne", "internalURL": "http://192.168.0.2:8080/v1/AUTH_8eee400f
+ 7a8a4f35b7a92bc6cb54de42", "id": "081a50a3c9fa49719673a52420a87557", "publicURL
+ ": "http://172.16.1.2:8080/v1/AUTH_8eee400f7a8a4f35b7a92bc6cb54de42"}], "endpoi
+ nts_links": [], "type": "object-store", "name": "swift"}, {"endpoints": [{"admi
+ nURL": "http://192.168.0.2:35357/v2.0", "region": "RegionOne", "internalURL": "
+ http://192.168.0.2:5000/v2.0", "id": "057a7f8e9a9f4defb1966825de957f5b", "publi
+ cURL": "http://172.16.1.2:5000/v2.0"}], "endpoints_links": [], "type": "identit
+ y", "name": "keystone"}], "user": {"username": "admin", "roles_links": [], "id"
+ : "717701504566411794a9cfcea1a85c1f", "roles": [{"name": "admin"}], "name": "ad
+ min"}, "metadata": {"is_admin": 0, "roles": ["90a1f4f29aef48d7bce3ada631a54261"
+ ]}}}
+ REQ: curl -i http://172.16.1.2:8774/v2/8eee400f7a8a4f35b7a92bc6cb54de42/servers/
+ detail -X GET -H "X-Auth-Project-Id: admin" -H "User-Agent: python-novaclient" -
+ H "Accept: application/json" -H "X-Auth-Token: c321cd823c8a4852aea4b870a03c8f72"
- REQ: curl -i http://240.0.1.5:8774/v2/1a491e1416d041da93daae1dc8af6d07/servers/d
- etail -X GET -H "X-Auth-Project-Id: admin" -H "User-Agent: python-novaclient" -H
- "Accept: application/json" -H "X-Auth-Token: d9ab5c927bcb410d9e9ee5bdea3ea020"
-
- INFO (connectionpool:191) Starting new HTTP connection (1): 240.0.1.5
+ INFO (connectionpool:191) Starting new HTTP connection (1): 172.16.1.2
Even though initial connection was in 192.168.0.5, then client tries to
-access public network for Nova API. The reason is because Keystone returns
+access Public network for Nova API. The reason is because Keystone returns
the list of OpenStack services URLs, and for production-grade deployments it
is required to access services over public network. If you still need to
work with OpenStack API without routing configured, tell us your use case on
diff --git a/pages/installation-fuel-ui/networks.rst b/pages/installation-fuel-ui/networks.rst
index 3a4f6ca84..073521d53 100644
--- a/pages/installation-fuel-ui/networks.rst
+++ b/pages/installation-fuel-ui/networks.rst
@@ -1,10 +1,12 @@
-Understanding and configuring the network
+.. index:: Fuel UI; Network Configuration
+
+Understanding and Configuring the Network
=========================================
-.. contents:: :local:
+.. contents :local:
OpenStack clusters use several types of network managers: FlatDHCPManager,
-VlanManager and Neutron (formerly Quantum). The current version of Fuel UI
+VLANManager and Neutron (formerly Quantum). The current version of Fuel UI
supports only two (FlatDHCP and VlanManager), but Fuel CLI supports all
three. For more information about how the first two network managers work,
you can read these two resources:
@@ -15,7 +17,7 @@ you can read these two resources:
`_
FlatDHCPManager (multi-host scheme)
-------------------------------------
+-----------------------------------
The main idea behind the flat network manager is to configure a bridge
(i.e. **br100**) on every compute node and have one of the machine's host
@@ -31,49 +33,7 @@ interface is used to give network access to virtual machines, while **eth0**
interface is the management network interface.
.. image:: /_images/flatdhcpmanager-mh_scheme.jpg
- :width: 600px
-
-..
- .. uml::
- node "Compute1" {
- [eth1\nVM] as compute1_eth1
- [eth0\nManagement] as compute1_eth0
- [vm0] as compute1_vm0
- [vm1] as compute1_vm1
- [br100] as compute1_br100
- compute1_br100 -up- compute1_eth1
- compute1_vm0 -up- compute1_br100
- compute1_vm1 -up- compute1_br100
- }
-
- node "Compute2" {
- [eth1\nVM] as compute2_eth1
- [eth0\nManagement] as compute2_eth0
- [vm0] as compute2_vm0
- [vm1] as compute2_vm1
- [br100] as compute2_br100
- compute2_br100 -up- compute2_eth1
- compute2_vm0 -up- compute2_br100
- compute2_vm1 -up- compute2_br100
- }
-
- node "Compute3" {
- [eth1\nVM] as compute3_eth1
- [eth0\nManagement] as compute3_eth0
- [vm0] as compute3_vm0
- [vm1] as compute3_vm1
- [br100] as compute3_br100
- compute3_br100 -up- compute3_eth1
- compute3_vm0 -up- compute3_br100
- compute3_vm1 -up- compute3_br100
- }
-
- compute1_eth1 -up- [L2 switch]
- compute2_eth1 -up- [L2 switch]
- compute3_eth1 -up- [L2 switch]
- compute1_eth0 .up. [L2 switch]
- compute2_eth0 .up. [L2 switch]
- compute3_eth0 .up. [L2 switch]
+ :align: center
Fuel deploys OpenStack in FlatDHCP mode with the so called **multi-host**
feature enabled. Without this feature enabled, network traffic from each VM
@@ -89,53 +49,10 @@ the physical network interfaces that are connected to the bridge, but the
VLAN interface (i.e. **eth0.102**).
FlatDHCPManager (single-interface scheme)
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-
+-----------------------------------------
.. image:: /_images/flatdhcpmanager-mh_scheme.jpg
- :width: 600px
-
-..
- .. uml::
- node "Compute1 Node" {
- [eth0] as compute1_eth0
- [eth0.101\nManagement] as compute1_eth0_101
- [eth0.102\nVM] as compute1_eth0_102
- [vm0] as compute1_vm0
- [vm1] as compute1_vm1
- [vm2] as compute1_vm2
- [vm3] as compute1_vm3
- [br100] as compute1_br100
- compute1_eth0 -down- compute1_eth0_101
- compute1_eth0 -down- compute1_eth0_102
- compute1_eth0_102 -down- compute1_br100
- compute1_br100 -down- compute1_vm0
- compute1_br100 -down- compute1_vm1
- compute1_br100 -down- compute1_vm2
- compute1_br100 -down- compute1_vm3
- }
-
- node "Compute2 Node" {
- [eth0] as compute2_eth0
- [eth0.101\nManagement] as compute2_eth0_101
- [eth0.102\nVM] as compute2_eth0_102
- [vm0] as compute2_vm0
- [vm1] as compute2_vm1
- [vm2] as compute2_vm2
- [vm3] as compute2_vm3
- [br100] as compute2_br100
- compute2_eth0 -down- compute2_eth0_101
- compute2_eth0 -down- compute2_eth0_102
- compute2_eth0_102 -down- compute2_br100
- compute2_br100 -down- compute2_vm0
- compute2_br100 -down- compute2_vm1
- compute2_br100 -down- compute2_vm2
- compute2_br100 -down- compute2_vm3
- }
-
- compute1_eth0 -up- [L2 switch]
- compute2_eth0 -up- [L2 switch]
+ :align: center
Therefore all switch ports where compute nodes are connected must be
configured as tagged (trunk) ports with required vlans allowed (enabled,
@@ -157,59 +74,12 @@ VMs of other projects. Switch ports must be configured as tagged (trunk)
ports to allow this scheme to work.
.. image:: /_images/flatdhcpmanager-mh_scheme.jpg
- :width: 600px
+ :align: center
-..
- .. uml::
- node "Compute1 Node" {
- [eth0] as compute1_eth0
- [eth0.101\nManagement] as compute1_eth0_101
- [vlan102\n] as compute1_vlan102
- [vlan103\n] as compute1_vlan103
- [vm0] as compute1_vm0
- [vm1] as compute1_vm1
- [vm2] as compute1_vm2
- [vm3] as compute1_vm3
- [br102] as compute1_br102
- [br103] as compute1_br103
- compute1_eth0 -down- compute1_eth0_101
- compute1_eth0 -down- compute1_vlan102
- compute1_eth0 -down- compute1_vlan103
- compute1_vlan102 -down- compute1_br102
- compute1_vlan103 -down- compute1_br103
- compute1_br102 -down- compute1_vm0
- compute1_br102 -down- compute1_vm1
- compute1_br103 -down- compute1_vm2
- compute1_br103 -down- compute1_vm3
- }
+.. index:: Fuel UI; Deployment Schema
- node "Compute2 Node" {
- [eth0] as compute2_eth0
- [eth0.101\nManagement] as compute2_eth0_101
- [vlan102\n] as compute2_vlan102
- [vlan103\n] as compute2_vlan103
- [vm0] as compute2_vm0
- [vm1] as compute2_vm1
- [vm2] as compute2_vm2
- [vm3] as compute2_vm3
- [br102] as compute2_br102
- [br103] as compute2_br103
- compute2_eth0 -down- compute2_eth0_101
- compute2_eth0 -down- compute2_vlan102
- compute2_eth0 -down- compute2_vlan103
- compute2_vlan102 -down- compute2_br102
- compute2_vlan103 -down- compute2_br103
- compute2_br102 -down- compute2_vm0
- compute2_br102 -down- compute2_vm1
- compute2_br103 -down- compute2_vm2
- compute2_br103 -down- compute2_vm3
- }
-
- compute1_eth0 -up- [L2 switch]
- compute2_eth0 -up- [L2 switch]
-
-Fuel deployment schema
-^^^^^^^^^^^^^^^^^^^^^^
+Fuel Deployment Schema
+======================
One of the physical interfaces on each host has to be chosen to carry
VM-to-VM traffic (fixed network), and switch ports must be configured to
@@ -225,7 +95,8 @@ Once you choose a networking mode (FlatDHCP/VLAN), you must configure equipment
accordingly. The diagram below shows an example configuration.
.. image:: /_images/physical-network.jpg
- :width: 600px
+ :width: 100%
+ :align: center
Fuel operates with following logical networks:
@@ -251,7 +122,7 @@ Fuel operates with following logical networks:
networks (vlan 104 on the scheme).
Mapping logical networks to physical interfaces on servers
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Fuel allows you to use different physical interfaces to handle different
types of traffic. When a node is added to the environment, click at the bottom
@@ -259,7 +130,7 @@ line of the node icon. In the detailed information window, click the "Network
Configuration" button to open the physical interfaces configuration screen.
.. image:: /_images/network-settings.jpg
- :width: 600px
+ :align: center
On this screen you can drag-and-drop logical networks to physical interfaces
according to your network setup.
@@ -272,7 +143,7 @@ you may not modify network settings, even to move a logical network to another
physical interface or VLAN number.
Switch
-^^^^^^
+++++++
Fuel can configure hosts, however switch configuration is still manual work.
Unfortunately the set of configuration steps, and even the terminology used,
@@ -347,7 +218,7 @@ Example configuration for one of the ports on a Cisco switch::
vlan 262,100,102,104 # Might be needed for enabling VLANs
Router
-^^^^^^
+++++++
To make it possible for VMs to access the outside world, you must have an IP
address set on a router in the public network. In the examples provided,
diff --git a/pages/installation-fuel-ui/post-install-healthchecks.rst b/pages/installation-fuel-ui/post-install-healthchecks.rst
index 49869275e..963167e6b 100644
--- a/pages/installation-fuel-ui/post-install-healthchecks.rst
+++ b/pages/installation-fuel-ui/post-install-healthchecks.rst
@@ -1,9 +1,11 @@
+.. index:: Fuel UI; Post-Deployment Check
+
.. _Post-Deployment-Check:
Post-Deployment Check
=====================
-.. contents:: :local:
+.. contents :local:
On occasion, even a successful deployment may result in some OpenStack
components not working correctly. If this happens, Fuel offers the
@@ -28,7 +30,6 @@ is by their names. Sanity Checks are intended to assist in maintaining your
sanity. Smoke Checks tell you where the fires are so you can put them out
strategically instead of firehosing the entire installation.
-
Benefits
--------
@@ -57,6 +58,7 @@ Now, let`s take a closer look on what should be done to execute the tests and
to understand if something is wrong with your OpenStack cluster.
.. image:: /_images/healthcheck_tab.jpg
+ :align: center
As you can see on the image above, the Fuel UI now contains a ``Healthcheck``
tab, indicated by the Heart icon.
@@ -85,9 +87,10 @@ this section.
An actual test run looks like this:
.. image:: /_images/ostf_screen.jpg
+ :align: center
What should be done when a test failed
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+--------------------------------------
If a test failed, there are several ways to investigate the problem. You may
prefer to start in Fuel UI since it's feedback is directly related to the
@@ -111,11 +114,11 @@ The first thing to be done is to ensure all OpenStack services are up and runnin
To do this you can run sanity test set, or execute the following command on your
controller node::
- nova-manage service list
+ nova-manage service list
If any service is off (has “XXX” status), you can restart it using this command::
- service openstack- restart
+ service openstack- restart
If all services are on, but you`re still experiencing some issues, you can
gather information on OpenStack Dashboard (exceeded number of instances,
@@ -126,7 +129,7 @@ have underprovisioned your environment and should check your math and your
project requirements.
Sanity tests description
-^^^^^^^^^^^^^^^^^^^^^^^^
+------------------------
Sanity checks work by sending a query to all OpenStack components to get a
response back from them. Many of these tests are simple in that they ask
@@ -137,119 +140,119 @@ what test is used for each service:
.. topic:: Instances list availability
- Test checks that Nova component can return list of instances.
+ Test checks that Nova component can return list of instances.
- Test scenario:
+ Test scenario:
- 1. Request list of instances.
- 2. Check returned list is not empty.
+ 1. Request list of instances.
+ 2. Check returned list is not empty.
.. topic:: Images list availability
- Test checks that Glance component can return list of images.
+ Test checks that Glance component can return list of images.
- Test scenario:
+ Test scenario:
- 1. Request list of images.
- 2. Check returned list is not empty.
+ 1. Request list of images.
+ 2. Check returned list is not empty.
.. topic:: Volumes list availability
- Test checks that Swift component can return list of volumes.
+ Test checks that Swift component can return list of volumes.
- Test scenario:
+ Test scenario:
- 1. Request list of volumes.
- 2. Check returned list is not empty.
+ 1. Request list of volumes.
+ 2. Check returned list is not empty.
.. topic:: Snapshots list availability
- Test checks that Glance component can return list of snapshots.
+ Test checks that Glance component can return list of snapshots.
- Test scenario:
+ Test scenario:
- 1. Request list of snapshots.
- 2. Check returned list is not empty.
+ 1. Request list of snapshots.
+ 2. Check returned list is not empty.
.. topic:: Flavors list availability
- Test checks that Nova component can return list of flavors.
+ Test checks that Nova component can return list of flavors.
- Test scenario:
+ Test scenario:
- 1. Request list of flavors.
- 2. Check returned list is not empty.
+ 1. Request list of flavors.
+ 2. Check returned list is not empty.
.. topic:: Limits list availability
- Test checks that Nova component can return list of absolute limits.
+ Test checks that Nova component can return list of absolute limits.
- Test scenario:
+ Test scenario:
- 1. Request list of limits.
- 2. Check response.
+ 1. Request list of limits.
+ 2. Check response.
.. topic:: Services list availability
- Test checks that Nova component can return list of services.
+ Test checks that Nova component can return list of services.
- Test scenario:
+ Test scenario:
- 1. Request list of services.
- 2. Check returned list is not empty.
+ 1. Request list of services.
+ 2. Check returned list is not empty.
.. topic:: User list availability
- Test checks that Keystone component can return list of users.
+ Test checks that Keystone component can return list of users.
- Test scenario:
+ Test scenario:
- 1. Request list of services.
- 2. Check returned list is not empty.
+ 1. Request list of services.
+ 2. Check returned list is not empty.
.. topic:: Services execution monitoring
- Test checks that all of the expected services are on, meaning the test will
- fail if any of the listed services is in “XXX” status.
+ Test checks that all of the expected services are on, meaning the test will
+ fail if any of the listed services is in “XXX” status.
- Test scenario:
+ Test scenario:
- 1. Connect to a controller via SSH.
- 2. Execute nova-manage service list command.
- 3. Check there are no failed services.
+ 1. Connect to a controller via SSH.
+ 2. Execute nova-manage service list command.
+ 3. Check there are no failed services.
.. topic:: DNS availability
- Test checks that DNS is available.
+ Test checks that DNS is available.
- Test scenario:
+ Test scenario:
- 1. Connect to a controller node via SSH.
- 2. Execute host command for the controller IP.
- 3. Check DNS name can be successfully resolved.
+ 1. Connect to a controller node via SSH.
+ 2. Execute host command for the controller IP.
+ 3. Check DNS name can be successfully resolved.
.. topic:: Networks availability
- Test checks that Nova component can return list of available networks.
-
- Test scenario:
-
- 1. Request list of networks.
- 2. Check returned list is not empty.
+ Test checks that Nova component can return list of available networks.
+
+ Test scenario:
+
+ 1. Request list of networks.
+ 2. Check returned list is not empty.
.. topic:: Ports availability
- Test checks that Nova component can return list of available ports.
+ Test checks that Nova component can return list of available ports.
- Test scenario:
+ Test scenario:
- 1. Request list of ports.
- 2. Check returned list is not empty.
+ 1. Request list of ports.
+ 2. Check returned list is not empty.
For more information refer to nova cli reference.
Smoke tests description
-^^^^^^^^^^^^^^^^^^^^^^^
+-----------------------
Smoke tests verify how your system handles basic OpenStack operations under
normal circumstances. The Smoke test series uses timeout tests for
@@ -265,158 +268,161 @@ negatives. The following is a description of each sanity test available:
.. topic:: Flavor creation
- Test checks that low requirements flavor can be created.
+ Test checks that low requirements flavor can be created.
- Target component: Nova
+ Target component: Nova
- Scenario:
+ Scenario:
- 1. Create small-size flavor.
- 2. Check created flavor has expected name.
- 3. Check flavor disk has expected size.
+ 1. Create small-size flavor.
+ 2. Check created flavor has expected name.
+ 3. Check flavor disk has expected size.
- For more information refer to nova cli reference.
+ For more information refer to nova cli reference.
.. topic:: Volume creation
- Test checks that a small-sized volume can be created.
+ Test checks that a small-sized volume can be created.
- Target component: Compute
+ Target component: Compute
- Scenario:
+ Scenario:
- 1. Create a new small-size volume.
- 2. Wait for "available" volume status.
- 3. Check response contains "display_name" section.
- 4. Create instance and wait for "Active" status
- 5. Attach volume to instance.
- 6. Check volume status is "in use".
- 7. Get created volume information by its id.
- 8. Detach volume from instance.
- 9. Check volume has "available" status.
- 10. Delete volume.
+ 1. Create a new small-size volume.
+ 2. Wait for "available" volume status.
+ 3. Check response contains "display_name" section.
+ 4. Create instance and wait for "Active" status
+ 5. Attach volume to instance.
+ 6. Check volume status is "in use".
+ 7. Get created volume information by its id.
+ 8. Detach volume from instance.
+ 9. Check volume has "available" status.
+ 10. Delete volume.
- If you see that created volume is in ERROR status, it can mean that you`ve
- exceeded the maximum number of volumes that can be created. You can check it
- on OpenStack dashboard. For more information refer to volume management
- instructions.
+ If you see that created volume is in ERROR status, it can mean that you`ve
+ exceeded the maximum number of volumes that can be created. You can check it
+ on OpenStack dashboard. For more information refer to volume management
+ instructions.
.. topic:: Instance booting and snapshotting
- Test creates a keypair, checks that instance can be booted from default
- image, then a snapshot can be created from it and a new instance can be
- booted from a snapshot. Test also verifies that instances and images reach
- ACTIVE state upon their creation.
+ Test creates a keypair, checks that instance can be booted from default
+ image, then a snapshot can be created from it and a new instance can be
+ booted from a snapshot. Test also verifies that instances and images reach
+ ACTIVE state upon their creation.
- Target component: Glance
+ Target component: Glance
- Scenario:
+ Scenario:
- 1. Create new keypair to boot an instance.
- 2. Boot default image.
- 3. Make snapshot of created server.
- 4. Boot another instance from created snapshot.
-
- If you see that created instance is in ERROR status, it can mean that you`ve
- exceeded any system requirements limit. The test is using a nano-flavor with
- parameters: 64 RAM, 1 GB disk space, 1 virtual CPU presented. For more
- information refer to nova cli reference, image management instructions.
+ 1. Create new keypair to boot an instance.
+ 2. Boot default image.
+ 3. Make snapshot of created server.
+ 4. Boot another instance from created snapshot.
+
+ If you see that created instance is in ERROR status, it can mean that you`ve
+ exceeded any system requirements limit. The test is using a nano-flavor with
+ parameters: 64 RAM, 1 GB disk space, 1 virtual CPU presented. For more
+ information refer to nova cli reference, image management instructions.
.. topic:: Keypair creation
- Target component: Nova.
+ Target component: Nova.
- Scenario:
+ Scenario:
- 1. Create a new keypair, check if it was created successfully
- (check name is expected, response status is 200).
+ 1. Create a new keypair, check if it was created successfully
+ (check name is expected, response status is 200).
- For more information refer to nova cli reference.
+ For more information refer to nova cli reference.
.. topic:: Security group creation
- Target component: Nova
+ Target component: Nova
- Scenario:
+ Scenario:
- 1. Create security group, check if it was created correctly
- (check name is expected, response status is 200).
+ 1. Create security group, check if it was created correctly
+ (check name is expected, response status is 200).
- For more information refer to nova cli reference.
+ For more information refer to nova cli reference.
.. topic:: Network parameters check
- Target component: Nova
+ Target component: Nova
- Scenario:
+ Scenario:
- 1. Get list of networks.
- 2. Check seen network labels equal to expected ones.
- 3. Check seen network ids equal to expected ones.
+ 1. Get list of networks.
+ 2. Check seen network labels equal to expected ones.
+ 3. Check seen network ids equal to expected ones.
- For more information refer to nova cli reference.
+ For more information refer to nova cli reference.
.. topic:: Instance creation
- Target component: Nova
- Scenario:
+ Target component: Nova
- 1. Create new keypair (if it`s nonexistent yet).
- 2. Create new sec group (if it`s nonexistent yet).
- 3. Create instance with usage of created sec group and keypair.
+ Scenario:
- For more information refer to nova cli reference, instance management
- instructions.
+ 1. Create new keypair (if it`s nonexistent yet).
+ 2. Create new sec group (if it`s nonexistent yet).
+ 3. Create instance with usage of created sec group and keypair.
+
+ For more information refer to nova cli reference, instance management
+ instructions.
.. topic:: Floating IP assignment
- Target component: Nova
+ Target component: Nova
- Scenario:
+ Scenario:
- 1. Create new keypair (if it`s nonexistent yet).
- 2. Create new sec group (if it`s nonexistent yet).
- 3. Create instance with usage of created sec group and keypair.
- 4. Create new floating ip.
- 5. Assign floating ip to created instance.
-
- For more information refer to nova cli reference, floating ips management
- instructions.
+ 1. Create new keypair (if it`s nonexistent yet).
+ 2. Create new sec group (if it`s nonexistent yet).
+ 3. Create instance with usage of created sec group and keypair.
+ 4. Create new floating IP.
+ 5. Assign floating IP to created instance.
+
+ For more information refer to nova cli reference, floating ips management
+ instructions.
.. topic:: Network connectivity check through floating IP
- Target component: Nova
+ Target component: Nova
- Scenario:
+ Scenario:
- 1. Create new keypair (if it`s nonexistent yet).
- 2. Create new sec group (if it`s nonexistent yet).
- 3. Create instance with usage of created sec group and keypair.
- 4. Check connectivity for all floating ips using ping command.
+ 1. Create new keypair (if it`s nonexistent yet).
+ 2. Create new sec group (if it`s nonexistent yet).
+ 3. Create instance with usage of created sec group and keypair.
+ 4. Check connectivity for all floating IPs using ping command.
- If this test failed, it`s better to run a network check and verify that all
- connections are correct. For more information refer to the Nova CLI reference's
- floating IPs management instructions.
+ If this test failed, it`s better to run a network check and verify that all
+ connections are correct. For more information refer to the Nova CLI reference's
+ floating IPs management instructions.
.. topic:: User creation and authentication in Horizon
- Test creates new user, tenant, user role with admin privileges and logs in
- to dashboard. Target components: Nova, Keystone
+ Test creates new user, tenant, user role with admin privileges and logs in
+ to dashboard.
+
+ Target components: Nova, Keystone
- Scenario:
+ Scenario:
- 1. Create a new tenant.
- 2. Check tenant was created successfully.
- 3. Create a new user.
- 4. Check user was created successfully.
- 5. Create a new user role.
- 6. Check user role was created successfully.
- 7. Perform token authentication.
- 8. Check authentication was successful.
- 9. Send authentication request to Horizon.
- 10. Verify response status is 200.
+ 1. Create a new tenant.
+ 2. Check tenant was created successfully.
+ 3. Create a new user.
+ 4. Check user was created successfully.
+ 5. Create a new user role.
+ 6. Check user role was created successfully.
+ 7. Perform token authentication.
+ 8. Check authentication was successful.
+ 9. Send authentication request to Horizon.
+ 10. Verify response status is 200.
- If this test fails on the authentication step, you should first try opening
- the dashboard - it may be unreachable for some reason and then you should
- check your network configuration. For more information refer to nova cli
- reference.
+ If this test fails on the authentication step, you should first try opening
+ the dashboard - it may be unreachable for some reason and then you should
+ check your network configuration. For more information refer to nova cli
+ reference.
diff --git a/pages/installation-fuel-ui/red_hat_openstack.rst b/pages/installation-fuel-ui/red_hat_openstack.rst
index f515f59eb..ed959cacc 100644
--- a/pages/installation-fuel-ui/red_hat_openstack.rst
+++ b/pages/installation-fuel-ui/red_hat_openstack.rst
@@ -1,7 +1,9 @@
+.. index:: Red Hat OpenStack
+
Red Hat OpenStack Notes
=======================
-.. contents:: :local:
+.. contents :local:
Overview
--------
@@ -14,33 +16,34 @@ Red Hat account credentials in order to download Red Hat OpenStack Platform.
The necessary components will be prepared and loaded into Cobbler. There are
two methods Fuel supports for obtaining Red Hat OpenStack packages:
-* Red Hat Subscription Manager (RHSM)
-* and Red Hat RHN Satellite.
+* :ref:`RHSM` (default)
+* :ref:`RHN_Satellite`
+
+.. index:: Red Hat OpenStack; Deployment Requirements
+
+Deployment Requirements
+-----------------------
Minimal Requirements
-^^^^^^^^^^^^^^^^^^^^
+++++++++++++++++++++
* Red Hat account (https://access.redhat.com)
-* Red Hat OpenStack entitlement (one per host)
-* Internet access for Fuel master host
+* Red Hat OpenStack entitlement (one per node)
+* Internet access for Fuel Master name
Optional requirements
-^^^^^^^^^^^^^^^^^^^^^
++++++++++++++++++++++
* Red Hat Satellite Server
* Configured Satellite activation key
-Deployment types
-^^^^^^^^^^^^^^^^
+.. _RHSM:
-* `Red Hat Subscription Management `_ (default)
-* `Red Hat RHN Satellite `_
-
-Red Hat Subscription Management overview
-----------------------------------------
+Red Hat Subscription Management (RHSM)
+--------------------------------------
Benefits
-^^^^^^^^
+++++++++
* No need to handle large ISOs or physical media.
* Register all your clients with just a single username and password.
@@ -50,16 +53,22 @@ Benefits
* Download only necessary packages.
Considerations
-^^^^^^^^^^^^^^
+++++++++++++++
* Must observe Red Hat licensing requirements after deployment
* Package download time is dependent on network speed (20-60 minutes)
-Red Hat RHN Satellite overview
-------------------------------
+.. seealso::
+
+ `Overview of Subscription Management - Red Hat Customer Portal `_
+
+.. _RHN_Satellite:
+
+Red Hat RHN Satellite
+---------------------
Benefits
-^^^^^^^^
+++++++++
* Faster download of Red Hat OpenStack packages
* Register all your clients with an activation key
@@ -68,7 +77,7 @@ Benefits
* Easier to consume for large enterprise customers
Considerations
-^^^^^^^^^^^^^^
+++++++++++++++
* Red Hat RHN Satellite is a separate offering from Red Hat and requires
dedicated hardware
@@ -76,7 +85,7 @@ Considerations
registration packages (just for Fuel Master host)
What you need
-^^^^^^^^^^^^^
++++++++++++++
* Red Hat account (https://access.redhat.com)
* Red Hat OpenStack entitlement (one per host)
@@ -85,7 +94,7 @@ What you need
* Configured Satellite activation key
Your RHN Satellite activation key must be configured the following channels
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
* RHEL Server High Availability
* RHEL Server Load Balancer
@@ -94,6 +103,10 @@ Your RHN Satellite activation key must be configured the following channels
* RHN Tools for RHEL
* Red Hat OpenStack 3.0
+.. seealso::
+
+ `Red Hat | Red Hat Network Satellite `_
+
.. _rhn_sat_channels:
Fuel looks for the following RHN Satellite channels.
@@ -106,11 +119,13 @@ Fuel looks for the following RHN Satellite channels.
.. note:: If you create cloned channels, leave these channel strings intact.
+.. index:: Red Hat OpenStack; Troubleshooting
+
Troubleshooting
---------------
Issues downloading from Red Hat Subscription Manager
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+++++++++++++++++++++++++++++++++++++++++++++++++++++
If you receive an error from Fuel UI regarding Red Hat OpenStack download
issues, ensure that you have a valid subscription to the Red Hat OpenStack
@@ -123,7 +138,7 @@ subscriptions associated with your account.
If you are still encountering issues, contact Mirantis Support.
Issues downloading from Red Hat RHN Satellite
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++++++++++++++++++++++++++++++++++++++++++++++
If you receive an error from Fuel UI regarding Red Hat OpenStack download
issues, ensure that you have all the necessary channels available on your
@@ -134,7 +149,7 @@ representative `_ to get
the proper subscriptions associated with your account.
RHN Satellite error: "rhel-x86_64-server-rs-6 not found"
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This means your Red Hat Satellite Server has run out of available entitlements
or your licenses have expired. Check your RHN Satellite to ensure there is at
@@ -146,7 +161,7 @@ account, please contact your `Red Hat sales representative
subscriptions associated with your account.
Yum Error: Cannot retrieve repository metadata (repomd.xml) for repository: rhel-x86_64-server-6.
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This can be caused by many problems. This could happen if your SSL
certificate does not match the hostname of your RHN Satellite Server or if
@@ -159,7 +174,7 @@ You may find solutions to your issues with repomd.xml at the
`Red Hat Support. `_.
GPG Key download failed. Looking for URL your-satellite-server/pub/RHN-ORG-TRUSTED-SSL-CERT
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
This issue has two known problems. If you are using VirtualBox, this may not
be properly configured. Ensure that your upstream DNS resolver is correct
diff --git a/pages/production-considerations/0010-introduction.rst b/pages/production-considerations/0010-introduction.rst
index 1de9db820..66e6e5719 100644
--- a/pages/production-considerations/0010-introduction.rst
+++ b/pages/production-considerations/0010-introduction.rst
@@ -1,3 +1,8 @@
-Fuel simplifies the set up of an OpenStack cluster, affording you the ability to dig in and fully understand how OpenStack works. You can deploy on test hardware or in a virtualized environment and root around all you like, but when it comes time to deploy to production there are a few things to take into consideration.
+Fuel simplifies the set up of an OpenStack cluster, affording you the ability
+to dig in and fully understand how OpenStack works. You can deploy on test
+hardware or in a virtualized environment and root around all you like, but
+when it comes time to deploy to production there are a few things to take
+into consideration.
-In this section we will talk about such things including how to size your hardware and how to handle large-scale deployments.
\ No newline at end of file
+In this section we will talk about such things including how to size your
+hardware and how to handle large-scale deployments.
\ No newline at end of file
diff --git a/pages/production-considerations/0015-sizing-hardware.rst b/pages/production-considerations/0015-sizing-hardware.rst
index d15fbe4e6..643bb54ed 100644
--- a/pages/production-considerations/0015-sizing-hardware.rst
+++ b/pages/production-considerations/0015-sizing-hardware.rst
@@ -3,9 +3,9 @@
.. _Sizing_Hardware:
Sizing Hardware
----------------
+===============
-.. contents:: :local:
+.. contents :local:
One of the first questions people ask when planning an OpenStack deployment is
"what kind of hardware do I need?" There is no such thing as a one-size-fits-all
@@ -28,7 +28,7 @@ Your needs in each of these areas are going to determine your overall hardware
requirements.
Processing
-^^^^^^^^^^
+----------
In order to calculate how much processing power you need to acquire you will
need to determine the number of VMs your cloud will support. You must also
@@ -61,7 +61,7 @@ You will also need to take into account the following:
* Choose a good value CPU that supports the technologies you require.
Memory
-^^^^^^
+------
Continuing to use the example from the previous section, we need to determine
how much RAM will be required to support 17 VMs per server. Let's assume that
@@ -86,7 +86,7 @@ all core OS requirements.
You can adjust this calculation based on your needs.
Storage Space
-^^^^^^^^^^^^^
+-------------
When it comes to disk space there are several types that you need to consider:
@@ -125,7 +125,7 @@ it critical, a single server would need 18 drives, most likely 2.5" 15,000RPM
146GB SAS drives.
Throughput
-~~~~~~~~~~
+++++++++++
As far as throughput, that's going to depend on what kind of storage you choose.
In general, you calculate IOPS based on the packing density (drive IOPS * drives
@@ -161,7 +161,7 @@ replace the drive and push a new node copy. The remaining VMs carry whatever
additional load is present due to the temporary loss of one node.
Remote storage
-~~~~~~~~~~~~~~
+++++++++++++++
IOPS will also be a factor in determining how you plan to handle persistent
storage. For example, consider these options for laying out your 50 TB of remote
@@ -185,7 +185,7 @@ You can accomplish the same thing with a single 36 drive frame using 3 TB
drives, but this becomes a single point of failure in your cluster.
Object storage
-~~~~~~~~~~~~~~
+++++++++++++++
When it comes to object storage, you will find that you need more space than
you think. For example, this example specifies 50 TB of object storage.
@@ -209,7 +209,7 @@ each, but its not recommended due to the high cost of failure to replication
and capacity issues.
Networking
-^^^^^^^^^^
+----------
Perhaps the most complex part of designing an OpenStack cluster is the
networking.
@@ -235,7 +235,7 @@ decrease latency by using two 10 Gb links, bringing the bandwidth per VM to
consider.
Scalability and oversubscription
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+++++++++++++++++++++++++++++++++
It is one of the ironies of networking that 1Gb Ethernet generally scales
better than 10Gb Ethernet -- at least until 100Gb switches are more commonly
@@ -250,7 +250,7 @@ racks, so plan to create "pods", each of which includes both storage and
compute nodes. Generally, a pod is the size of a non-oversubscribed L2 domain.
Hardware for this example
-~~~~~~~~~~~~~~~~~~~~~~~~~
++++++++++++++++++++++++++
In this example, you are looking at:
@@ -264,7 +264,7 @@ switches. Also, as your network grows, you will need to consider uplinks and
aggregation switches.
Summary
-^^^^^^^
+-------
In general, your best bet is to choose a 2 socket server with a balance in I/O,
CPU, Memory, and Disk that meets your project requirements.
diff --git a/pages/production-considerations/0020-deployment-pipeline.rst b/pages/production-considerations/0020-deployment-pipeline.rst
index 599607ffc..9ff931ee5 100644
--- a/pages/production-considerations/0020-deployment-pipeline.rst
+++ b/pages/production-considerations/0020-deployment-pipeline.rst
@@ -3,9 +3,9 @@
.. _Redeploying_An_Environment:
Redeploying An Environment
---------------------------
+==========================
-.. contents:: :local:
+.. contents :local:
Because Puppet is additive only, there is no ability to revert changes as you
would in a typical application deployment. If a change needs to be backed out,
@@ -19,13 +19,13 @@ and minimizes the headaches associated with maintaining multiple configurations
through a single Puppet Master by creating what are called environments.
Environments
-^^^^^^^^^^^^
+------------
Puppet supports assigning nodes 'environments'. These environments can be
mapped directly to your development, QA and production life cycles, so it’s a
way to distribute code to nodes that are assigned to those environments.
-* On the Master Node
+* On the Master node
The Puppet Master tries to find modules using its ``modulepath`` setting,
which by default is ``/etc/puppet/modules``. It is common practice to set
@@ -35,16 +35,18 @@ way to distribute code to nodes that are assigned to those environments.
For example, you can specify several search paths. The following example
dynamically sets the ``modulepath`` so Puppet will check a per-environment
- folder for a module before serving it from the main set::
+ folder for a module before serving it from the main set:
- [master]
- modulepath = $confdir/$environment/modules:$confdir/modules
+.. code-block:: ini
- [production]
- manifest = $confdir/manifests/site.pp
+ [master]
+ modulepath = $confdir/$environment/modules:$confdir/modules
- [development]
- manifest = $confdir/$environment/manifests/site.pp
+ [production]
+ manifest = $confdir/manifests/site.pp
+
+ [development]
+ manifest = $confdir/$environment/manifests/site.pp
* On the Slave Node
@@ -53,13 +55,15 @@ way to distribute code to nodes that are assigned to those environments.
``production`` environment.
To set aslave-side environment, just specify the environment setting in the
- ``[agent]`` block of ``puppet.conf``::
+ ``[agent]`` block of ``puppet.conf``:
- [agent]
- environment = development
+.. code-block:: ini
+
+ [agent]
+ environment = development
Deployment pipeline
-^^^^^^^^^^^^^^^^^^^
+-------------------
* Deploy
diff --git a/pages/production-considerations/0030-large-deployments.rst b/pages/production-considerations/0030-large-deployments.rst
index c85b1efbb..aceb4fbf5 100644
--- a/pages/production-considerations/0030-large-deployments.rst
+++ b/pages/production-considerations/0030-large-deployments.rst
@@ -3,13 +3,11 @@
.. _Large_Scale_Deployments:
Large Scale Deployments
------------------------
+=======================
When deploying large clusters (of 100 nodes or more) there are two basic
bottlenecks:
-.. contents:: :local:
-
Careful planning is key to eliminating these potential problem areas, but
there's another way.
@@ -18,7 +16,7 @@ however, that it's always good to have a sense of how to solve these problems
should they appear.
Certificate signing requests and Puppet Master/Cobbler capacity
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+---------------------------------------------------------------
When deploying a large cluster, you may find that Puppet Master begins to have
difficulty when you start exceeding 20 or more simultaneous requests. Part of
@@ -52,9 +50,10 @@ combination of rsync (for modules, manifests, and SSL data) and database
replication.
.. image:: /_images/cobbler-puppet-ha.jpg
+ :align: center
Downloading of operating systems and other software
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+---------------------------------------------------
Large deployments can also suffer from a bottleneck in terms of the additional
traffic created by downloading software from external sources. One way to avoid
diff --git a/pages/reference-architecture/0010-overview.rst b/pages/reference-architecture/0010-overview.rst
index 0340a88c2..198c3ac12 100644
--- a/pages/reference-architecture/0010-overview.rst
+++ b/pages/reference-architecture/0010-overview.rst
@@ -1,7 +1,9 @@
+.. index:: Deployment Configurations
+
Overview
========
-.. contents:: :local:
+.. contents :local:
Before you install any hardware or software, you must know what
you're trying to achieve. This section looks at the basic components of
@@ -11,91 +13,38 @@ basis for installing OpenStack in the next section.
As you know, OpenStack provides the following basic services:
-.. topic:: Compute:
+**Compute:**
+ Compute servers are the workhorses of your installation; they're
+ the servers on which your users' virtual machines are created.
+ `nova-scheduler` controls the life-cycle of these VMs.
- Compute servers are the workhorses of your installation; they're
- the servers on which your users' virtual machines are created.
- `nova-scheduler` controls the life-cycle of these VMs.
+**Networking:**
+ Because an OpenStack cluster (virtually) always includes
+ multiple servers, the ability for them to communicate with each other and with
+ the outside world is crucial. Networking was originally handled by the
+ `nova-network` service, but it has given way to the newer Neutron (formerly
+ Quantum) networking service. Authentication and authorization for these
+ transactions are handled by `keystone`.
-.. topic:: Networking:
+**Storage:**
+ OpenStack provides for two different types of storage: block
+ storage and object storage. Block storage is traditional data storage, with
+ small, fixed-size blocks that are mapped to locations on storage media. At its
+ simplest level, OpenStack provides block storage using `nova-volume`, but it
+ is common to use `cinder`.
- Because an OpenStack cluster (virtually) always includes
- multiple servers, the ability for them to communicate with each other and with
- the outside world is crucial. Networking was originally handled by the
- `nova-network` service, but it has given way to the newer Neutron (formerly
- Quantum) networking service. Authentication and authorization for these
- transactions are handled by `keystone`.
+ Object storage, on the other hand, consists of single variable-size objects
+ that are described by system-level metadata, and you can access this capability
+ using `swift`.
-.. topic:: Storage:
-
- OpenStack provides for two different types of storage: block
- storage and object storage. Block storage is traditional data storage, with
- small, fixed-size blocks that are mapped to locations on storage media. At its
- simplest level, OpenStack provides block storage using `nova-volume`, but it
- is common to use `cinder`.
-
- Object storage, on the other hand, consists of single variable-size objects
- that are described by system-level metadata, and you can access this capability
- using `swift`.
-
- OpenStack storage is used for your users' objects, but it is also used for
- storing the images used to create new VMs. This capability is handled by `glance`.
+ OpenStack storage is used for your users' objects, but it is also used for
+ storing the images used to create new VMs. This capability is handled by `glance`.
These services can be combined in many different ways. Out of the box,
Fuel supports the following deployment configurations:
-.. index:: Deployment Configurations; Simple (non-HA)
-
-Simple (non-HA) deployment
---------------------------
-
-In a production environment, you will never have a Simple non-HA
-deployment of OpenStack, partly because it forces you to make a number
-of compromises as to the number and types of services that you can
-deploy. It is, however, extremely useful if you just want to see how
-OpenStack works from a user's point of view.
-
-.. image:: /_images/deployment-simple_svg.jpg
-
-More commonly, your OpenStack installation will consist of multiple
-servers. Exactly how many is up to you, of course, but the main idea
-is that your controller(s) are separate from your compute servers, on
-which your users' VMs will actually run. One arrangement that will
-enable you to achieve this separation while still keeping your
-hardware investment relatively modest is to house your storage on your
-controller nodes.
-
-.. index:: Deployment Configurations; Compact HA
-
-Multi-node (HA) deployment (Compact)
-------------------------------------
-
-Production environments typically require high availability, which
-involves several architectural requirements. Specifically, you will
-need at least three controllers, and
-certain components will be deployed in multiple locations to prevent
-single points of failure. That's not to say, however, that you can't
-reduce hardware requirements by combining your storage, network, and controller
-nodes:
-
-.. image:: /_images/deployment-ha-compact_svg.jpg
-
-.. index:: Deployment Configurations; Full HA
-
-Multi-node (HA) deployment (Full)
----------------------------------
-
-For large production deployments, its more common to provide
-dedicated hardware for storage. This architecture gives you the advantages of
-high availability, but this clean separation makes your cluster more
-maintainable by separating storage and controller functionality:
-
-.. image:: /_images/deployment-ha-full_svg.jpg
-
-Where Fuel really shines is in the creation of more complex architectures, so
-in this document you'll learn how to use Fuel to easily create a multi-node HA
-OpenStack cluster. To reduce the amount of hardware you'll need to follow the
-installation, however, the guide focuses on the Multi-node HA Compact
-architecture.
-
-Lets take a closer look at the details of this deployment configuration.
+- :ref:`Non-HA Simple `
+- :ref:`HA Compact `
+- :ref:`HA Full `
+- :ref:`RHOS Non-HA Simple `
+- :ref:`RHOS HA Compact `
diff --git a/pages/reference-architecture/0012-simple.rst b/pages/reference-architecture/0012-simple.rst
new file mode 100644
index 000000000..d5a52dce3
--- /dev/null
+++ b/pages/reference-architecture/0012-simple.rst
@@ -0,0 +1,23 @@
+.. index:: Deployment Configurations; Non-HA Simple
+
+.. _Simple:
+
+Simple (non-HA) deployment
+==========================
+
+In a production environment, you will never have a Simple non-HA
+deployment of OpenStack, partly because it forces you to make a number
+of compromises as to the number and types of services that you can
+deploy. It is, however, extremely useful if you just want to see how
+OpenStack works from a user's point of view.
+
+.. image:: /_images/deployment-simple_svg.jpg
+ :align: center
+
+More commonly, your OpenStack installation will consist of multiple
+servers. Exactly how many is up to you, of course, but the main idea
+is that your controller(s) are separate from your compute servers, on
+which your users' VMs will actually run. One arrangement that will
+enable you to achieve this separation while still keeping your
+hardware investment relatively modest is to house your storage on your
+controller nodes.
diff --git a/pages/reference-architecture/0014-compact.rst b/pages/reference-architecture/0014-compact.rst
new file mode 100644
index 000000000..52331ade0
--- /dev/null
+++ b/pages/reference-architecture/0014-compact.rst
@@ -0,0 +1,20 @@
+.. index:: Deployment Configurations; HA Compact
+
+.. _HA_Compact:
+
+Multi-node (HA) deployment (Compact)
+====================================
+
+Production environments typically require high availability, which
+involves several architectural requirements. Specifically, you will
+need at least three controllers, and
+certain components will be deployed in multiple locations to prevent
+single points of failure. That's not to say, however, that you can't
+reduce hardware requirements by combining your storage, network, and controller
+nodes:
+
+.. image:: /_images/deployment-ha-compact_svg.jpg
+ :align: center
+
+We'll take a closer look at the details of this deployment configuration in
+:ref:`Close_look_Compact` section.
diff --git a/pages/reference-architecture/0015-closer-look.rst b/pages/reference-architecture/0015-closer-look.rst
index 6b9078cf1..2058fffaa 100644
--- a/pages/reference-architecture/0015-closer-look.rst
+++ b/pages/reference-architecture/0015-closer-look.rst
@@ -1,3 +1,7 @@
+.. index:: Deployment Configurations; HA Compact Details
+
+.. _Close_look_Compact:
+
A closer look at the Multi-node (HA) Compact deployment
=======================================================
@@ -6,6 +10,7 @@ deployment configuration and how it achieves high availability. As you may
recall, this configuration looks something like this:
.. image:: /_images/deployment-ha-compact_svg.jpg
+ :align: center
OpenStack services are interconnected by RESTful HTTP-based APIs and
AMQP-based RPC messages. So redundancy for stateless OpenStack API
@@ -17,6 +22,7 @@ For example, RabbitMQ uses built-in clustering capabilities, while the
database uses MySQL/Galera replication.
.. image:: /_images/ha-overview_svg.jpg
+ :align: center
Lets take a closer look at what an OpenStack deployment looks like, and
what it will take to achieve high availability for an OpenStack
diff --git a/pages/reference-architecture/0016-full.rst b/pages/reference-architecture/0016-full.rst
new file mode 100644
index 000000000..1a6ac6dd2
--- /dev/null
+++ b/pages/reference-architecture/0016-full.rst
@@ -0,0 +1,20 @@
+.. index:: Deployment Configurations; HA Full
+
+.. _HA_Full:
+
+Multi-node (HA) deployment (Full)
+=================================
+
+For large production deployments, its more common to provide
+dedicated hardware for storage. This architecture gives you the advantages of
+high availability, but this clean separation makes your cluster more
+maintainable by separating storage and controller functionality:
+
+.. image:: /_images/deployment-ha-full_svg.jpg
+ :align: center
+
+Where Fuel really shines is in the creation of more complex architectures, so
+in this document you'll learn how to use Fuel to easily create a multi-node HA
+OpenStack cluster. To reduce the amount of hardware you'll need to follow the
+installation, however, the guide focuses on the Multi-node HA Compact
+architecture.
diff --git a/pages/reference-architecture/0016-red-hat-differences.rst b/pages/reference-architecture/0018-red-hat-differences.rst
similarity index 67%
rename from pages/reference-architecture/0016-red-hat-differences.rst
rename to pages/reference-architecture/0018-red-hat-differences.rst
index c7c11a221..487c2c802 100644
--- a/pages/reference-architecture/0016-red-hat-differences.rst
+++ b/pages/reference-architecture/0018-red-hat-differences.rst
@@ -1,7 +1,9 @@
-Red Hat OpenStack Overview
-==========================
+.. index:: Deployment Configurations; Red Hat OpenStack
-.. contents:: :local:
+Red Hat OpenStack Architectures
+===============================
+
+.. contents :local:
Red Hat has partnered with Mirantis to offer an end-to-end supported
distribution of OpenStack powered by Fuel. Because Red Hat offers support
@@ -11,27 +13,27 @@ a highly available OpenStack cluster.
Below is the list of modifications:
-.. topic:: Database backend:
+**Database backend:**
+ MySQL with Galera has been replaced with native replication in a
+ Master/Slave configuration. MySQL master is elected via Corosync
+ and master and slave status is managed via Pacemaker.
- MySQL with Galera has been replaced with native replication in a
- Master/Slave configuration. MySQL master is elected via Corosync
- and master and slave status is managed via Pacemaker.
+**Messaging backend:**
+ RabbitMQ has been replaced with QPID. Qpid is an AMQP provider that Red
+ Hat offers, but it cannot be clustered in Red Hat's offering. As a result,
+ Fuel configures three non-clustered, independent QPID brokers. Fuel still
+ offers HA for messaging backend via virtual IP management provided by
+ Corosync.
-.. topic:: Messaging backend:
+**Nova networking:**
+ Quantum is not available for Red Hat OpenStack because the Red Hat kernel
+ lacks GRE tunneling support for OpenVSwitch. This issue should be
+ fixed in a future release. As a result, Fuel for Red Hat OpenStack
+ Platform will only support Nova networking.
- RabbitMQ has been replaced with QPID. Qpid is an AMQP provider that Red
- Hat offers, but it cannot be clustered in Red Hat's offering. As a result,
- Fuel configures three non-clustered, independent QPID brokers. Fuel still
- offers HA for messaging backend via virtual IP management provided by
- Corosync.
-
-.. topic:: Nova networking:
-
- Quantum is not available for Red Hat OpenStack because the Red Hat kernel
- lacks GRE tunneling support for OpenVSwitch. This issue should be
- fixed in a future release. As a result, Fuel for Red Hat OpenStack
- Platform will only support Nova networking.
+.. index:: Deployment Configurations; Red Hat OpenStack; RHOS Non-HA Simple
+.. _RHOS_Simple:
Simple (non-HA) Red Hat OpenStack deployment
--------------------------------------------
@@ -43,6 +45,7 @@ deploy. It is, however, extremely useful if you just want to see how
OpenStack works from a user's point of view.
.. image:: /_images/deployment-simple_svg.jpg
+ :align: center
More commonly, your OpenStack installation will consist of multiple
servers. Exactly how many is up to you, of course, but the main idea
@@ -52,6 +55,10 @@ enable you to achieve this separation while still keeping your
hardware investment relatively modest is to house your storage on your
controller nodes.
+.. index:: Deployment Configurations; Red Hat OpenStack; RHOS HA Compact
+
+.. _RHOS_Compact:
+
Multi-node (HA) Red Hat OpenStack deployment (Compact)
------------------------------------------------------
@@ -64,6 +71,7 @@ reduce hardware requirements by combining your storage, network, and controller
nodes:
.. image:: /_images/deployment-ha-compact-red-hat_svg.jpg
+ :align: center
OpenStack services are interconnected by RESTful HTTP-based APIs and AMQP-based
RPC messages. So redundancy for stateless OpenStack API services is implemented
@@ -75,3 +83,4 @@ the help of Pacemaker), while QPID is offered in three independent brokers with
virtual IP management to provide high availability.
.. image:: /_images/ha-overview-red-hat_svg.jpg
+ :align: center
diff --git a/pages/reference-architecture/0020-logical-setup.rst b/pages/reference-architecture/0020-logical-setup.rst
index 209931b67..39ccec7f6 100644
--- a/pages/reference-architecture/0020-logical-setup.rst
+++ b/pages/reference-architecture/0020-logical-setup.rst
@@ -1,12 +1,12 @@
Logical Setup
=============
-.. contents:: :local:
+.. contents :local:
An OpenStack HA cluster involves, at a minimum, three types of nodes:
controller nodes, compute nodes, and storage nodes.
Controller Nodes
-^^^^^^^^^^^^^^^^
+----------------
The first order of business in achieving high availability (HA) is
redundancy, so the first step is to provide multiple controller nodes.
@@ -15,6 +15,7 @@ achieve HA, and Galera is a quorum-based system. That means that you must provid
at least 3 controller nodes.
.. image:: /_images/logical-diagram-controller_svg.jpg
+ :align: center
Every OpenStack controller runs HAProxy, which manages a single External
Virtual IP (VIP) for all controller nodes and provides HTTP and TCP load
@@ -42,7 +43,7 @@ mechanism for achieving HA:
* Quantum agents are managed by Pacemaker.
Compute Nodes
-^^^^^^^^^^^^^
+-------------
OpenStack compute nodes are, in many ways, the foundation of your
cluster; they are the servers on which your users will create their
@@ -53,9 +54,10 @@ redundancy to the end-users of Horizon and REST APIs, reaching out to
controller nodes using the VIP and going through HAProxy.
.. image:: /_images/logical-diagram-compute_svg.jpg
+ :align: center
Storage Nodes
-^^^^^^^^^^^^^
+-------------
In this OpenStack cluster reference architecture, shared storage acts
as a backend for Glance, so that multiple Glance instances running on
@@ -65,3 +67,4 @@ it not only for storing VM images, but also for any other objects such
as user files.
.. image:: /_images/logical-diagram-storage_svg.jpg
+ :align: center
diff --git a/pages/reference-architecture/0030-cluster-sizing.rst b/pages/reference-architecture/0030-cluster-sizing.rst
index 108d9f130..6d7ebce50 100644
--- a/pages/reference-architecture/0030-cluster-sizing.rst
+++ b/pages/reference-architecture/0030-cluster-sizing.rst
@@ -16,6 +16,7 @@ deployment is to allocate 4 nodes:
- 1 compute node
.. image:: /_images/deployment-ha-compact_svg.jpg
+ :align: center
If you want to run storage separately from the controllers, you can do that as
well by raising the bar to 9 nodes:
@@ -29,6 +30,7 @@ well by raising the bar to 9 nodes:
- 1 Compute node
.. image:: /_images/deployment-ha-full_svg.jpg
+ :align: center
Of course, you are free to choose how to deploy OpenStack based on the
amount of available hardware and on your goals (such as whether you
diff --git a/pages/reference-architecture/0040-network-setup.rst b/pages/reference-architecture/0040-network-setup.rst
index ed04e5ac2..f4dcaee27 100644
--- a/pages/reference-architecture/0040-network-setup.rst
+++ b/pages/reference-architecture/0040-network-setup.rst
@@ -3,18 +3,21 @@
Network Architecture
====================
-.. contents:: :local:
+.. contents :local:
The current architecture assumes the presence of 3 NICs, but it can be
customized for two or 4+ network interfaces. Most servers arebuilt with at least
two network interfaces. In this case, let's consider a typical example of three
NIC cards. They're utilized as follows:
-- **eth0**: the internal management network, used for communication with Puppet & Cobbler
+**eth0**:
+ The internal management network, used for communication with Puppet & Cobbler
-- **eth1**: the public network, and floating IPs assigned to VMs
+**eth1**:
+ The public network, and floating IPs assigned to VMs
-- **eth2**: the private network, for communication between OpenStack VMs, and the
+**eth2**:
+ The private network, for communication between OpenStack VMs, and the
bridge interface (VLANs)
In the multi-host networking mode, you can choose between the FlatDHCPManager
@@ -22,11 +25,12 @@ and VlanManager network managers in OpenStack. The figure below illustrates the
relevant nodes and networks.
.. image:: /_images/080-networking-diagram_svg.jpg
+ :align: center
Lets take a closer look at each network and how its used within the cluster.
Public Network
-^^^^^^^^^^^^^^
+--------------
This network allows inbound connections to VMs from the outside world (allowing
users to connect to VMs from the Internet). It also allows outbound connections
@@ -54,7 +58,7 @@ The public network also provides VIPs for Endpoint nodes, which are used to
connect to OpenStack services APIs.
Internal (Management) Network
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+-----------------------------
The internal network connects all OpenStack nodes in the cluster. All components
of an OpenStack cluster communicate with each other using this network. This
@@ -68,7 +72,7 @@ This network usually is a single C class network from your private, non-globally
routed IP address range.
Private Network
-^^^^^^^^^^^^^^^
+---------------
The private network facilitates communication between each tenant's VMs. Private
network address spaces are part of the enterprise network address space. Fixed
diff --git a/pages/reference-architecture/0060-quantum-vs-nova-network.rst b/pages/reference-architecture/0060-quantum-vs-nova-network.rst
index 5b4fc04b9..7a45a8492 100644
--- a/pages/reference-architecture/0060-quantum-vs-nova-network.rst
+++ b/pages/reference-architecture/0060-quantum-vs-nova-network.rst
@@ -1,7 +1,7 @@
Neutron vs. nova-network
-^^^^^^^^^^^^^^^^^^^^^^^^
+========================
-Neutron (formerly Quantum) is a service which provides networking-as-a-service
+Neutron (formerly Quantum) is a service which provides Networking-as-a-Service
functionality in OpenStack. It has a rich tenant-facing API for defining network
connectivity and addressing in the cloud, and gives operators the ability to
leverage different networking technologies to power their cloud networking.
diff --git a/pages/reference-architecture/0070-cinder-vs-nova-volume.rst b/pages/reference-architecture/0070-cinder-vs-nova-volume.rst
index 97bb69a78..91f21b6ad 100644
--- a/pages/reference-architecture/0070-cinder-vs-nova-volume.rst
+++ b/pages/reference-architecture/0070-cinder-vs-nova-volume.rst
@@ -1,5 +1,5 @@
Cinder vs. nova-volume
-^^^^^^^^^^^^^^^^^^^^^^
+======================
Cinder is a persistent storage management service, also known as
block-storage-as-a-service. It was created to replace nova-volume, and
diff --git a/pages/reference-architecture/0080-swift-notes.rst b/pages/reference-architecture/0080-swift-notes.rst
index 6736602eb..47e2bf1f4 100644
--- a/pages/reference-architecture/0080-swift-notes.rst
+++ b/pages/reference-architecture/0080-swift-notes.rst
@@ -2,24 +2,21 @@
.. _Swift-and-object-storage-notes:
-Object storage deployment notes
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Object Storage Deployment
+=========================
Fuel currently supports several scenarios to deploy the object storage:
-* Glance + filesystem
-
+**Glance + filesystem**
By default, Glance uses the file system backend to store virtual machine images.
In this case, you can use any of shared file systems supported by Glance.
-* Swift on controllers
-
+**Swift on controllers**
In this mode the role of swift-storage and swift-proxy are combined with a
nova-controller. Use it only for testing in order to save nodes. It's not
suitable for production environments.
-* Swift on dedicated nodes
-
+**Swift on dedicated nodes**
In this case the Proxy service and Storage (account/container/object) services
reside on separate nodes, with two proxy nodes and a minimum of three storage
nodes.
diff --git a/pages/reference-architecture/0090-ha-notes.rst b/pages/reference-architecture/0090-ha-notes.rst
new file mode 100644
index 000000000..08e6c2da4
--- /dev/null
+++ b/pages/reference-architecture/0090-ha-notes.rst
@@ -0,0 +1,404 @@
+.. index:: HA with Pacemaker and Corosync
+
+HA with Pacemaker and Corosync
+==============================
+
+.. index:: HA with Pacemaker and Corosync; Corosync settings
+
+Corosync settings
+-----------------
+
+Corosync is using Totem protocol which is an implementation of Virtual Synchrony
+protocol. It uses it in order to provide connectivity between cluster nodes,
+decide if cluster is quorate to provide services, to provide data layer for
+services that want to use features of Virtual Synchrony.
+
+Corosync is used in Fuel as communication and quorum service for Pacemaker
+cluster resource manager. It's main configuration file is located in
+``/etc/corosync/corosync.conf``.
+
+The main corosync section is `totem` section which describes how cluster nodes
+should communicate::
+
+ totem {
+ version: 2
+ token: 3000
+ token_retransmits_before_loss_const: 10
+ join: 60
+ consensus: 3600
+ vsftype: none
+ max_messages: 20
+ clear_node_high_bit: yes
+ rrp_mode: none
+ secauth: off
+ threads: 0
+ interface {
+ ringnumber: 0
+ bindnetaddr: 10.107.0.8
+ mcastaddr: 239.1.1.2
+ mcastport: 5405
+ }
+ }
+
+Corosync usually uses multicast UDP transport and sets "redundant ring" for
+communication. Currently Fuel deploys controllers with one redundant ring. Each
+ring has it’s own multicast address and bind net address that specifies on which
+interface corosync should join corresponding multicast group. Fuel uses default
+corosync configuration, which can also be altered in Fuel manifests.
+
+.. seealso:: ``man corosync.conf`` or corosync documentation at
+ http://clusterlabs.org/doc/ if you want to know how to tune installation
+ completely
+
+.. index:: HA with Pacemaker and Corosync; Pacemaker settings
+
+Pacemaker settings
+------------------
+
+Pacemaker is the cluster resource manager used by Fuel to manage Quantum
+resources, HAProxy, virtual IP addresses and MySQL Galera (or simple MySQL
+Master/slave replication in case of RHOS installation) cluster. It is done by
+use of Open Cluster Framework (see http://linux-ha.org/wiki/OCF_Resource_Agents )
+agent scripts which are deployed in order to start/stop/monitor Quantum services,
+to manage HAProxy, virtual IP addresses and MySQL replication. These are located
+at ``/usr/lib/ocf/resource.d/mirantis/quantum-agent-[ovs|dhcp|l3]``,
+``/usr/lib/ocf/resource.d/mirantis/mysql``, ``/usr/lib/ocf/resource.d/ocf/haproxy``.
+Firstly, MySQL agent is started, HAproxy and virtual IP addresses are set up.
+Then Open vSwitch and metadata agents are cloned on all the nodes. Then dhcp and
+L3 agents are started and tied together by use of pacemaker constraints called
+"colocation".
+
+.. seealso:: `Using Rules to Determine Resource
+ Location `_
+
+MySQL HA script primarily targets to the cluster rebuild after power failure or
+equal type of disaster - it needs working corosync in which it forms quorum of
+an epochs of replication and then electing master from node with newest epoch.
+Be aware of default five minute interval in which every cluster member should be
+booted to participate in such election. Every node is a self-aware, that means
+if nobody pushes higher epoch that it retrieved from corosync(neither no one did),
+it will just elect itself as a master.
+
+.. index:: HA with Pacemaker and Corosync; How Fuel Deploys HA
+
+How Fuel Deploys HA
+-------------------
+
+Fuel installs corosync service, configures `corosync.conf` and includes pacemaker
+service plugin into `/etc/corosync/service.d`. Then corosync service starts and
+spawns corresponding pacemaker processes. Fuel configures cluster properties of
+pacemaker and then injects resources configuration for virtual IPs, haproxy,
+mysql and quantum agent resources::
+
+ primitive p_haproxy ocf:pacemaker:haproxy \
+ op monitor interval="20" timeout="30" \
+ op start interval="0" timeout="30" \
+ op stop interval="0" timeout="30"
+ primitive p_mysql ocf:mirantis:mysql \
+ op monitor interval="60" timeout="30" \
+ op start interval="0" timeout="450" \
+ op stop interval="0" timeout="150"
+ primitive p_quantum-dhcp-agent ocf:mirantis:quantum-agent-dhcp \
+ op monitor interval="20" timeout="30" \
+ op start interval="0" timeout="360" \
+ op stop interval="0" timeout="360" \
+ params tenant="services" password="quantum" username="quantum" \
+ os_auth_url="http://10.107.2.254:35357/v2.0" \
+ meta is-managed="true"
+ primitive p_quantum-l3-agent ocf:mirantis:quantum-agent-l3 \
+ op monitor interval="20" timeout="30" \
+ op start interval="0" timeout="360" \
+ op stop interval="0" timeout="360" \
+ params tenant="services" password="quantum" syslog="true" username="quantum" \
+ debug="true" os_auth_url="http://10.107.2.254:35357/v2.0" \
+ meta is-managed="true" target-role="Started"
+ primitive p_quantum-metadata-agent ocf:mirantis:quantum-agent-metadata \
+ op monitor interval="60" timeout="30" \
+ op start interval="0" timeout="30" \
+ op stop interval="0" timeout="30"
+ primitive p_quantum-openvswitch-agent ocf:pacemaker:quantum-agent-ovs \
+ op monitor interval="20" timeout="30" \
+ op start interval="0" timeout="480" \
+ op stop interval="0" timeout="480"
+ primitive vip__management_old ocf:heartbeat:IPaddr2 \
+ op monitor interval="2" timeout="30" \
+ op start interval="0" timeout="30" \
+ op stop interval="0" timeout="30" \
+ params nic="br-mgmt" iflabel="ka" ip="10.107.2.254"
+ primitive vip__public_old ocf:heartbeat:IPaddr2 \
+ op monitor interval="2" timeout="30" \
+ op start interval="0" timeout="30" \
+ op stop interval="0" timeout="30" \
+ params nic="br-ex" iflabel="ka" ip="172.18.94.46"
+ clone clone_p_haproxy p_haproxy \
+ meta interleave="true"
+ clone clone_p_mysql p_mysql \
+ meta interleave="true" is-managed="true"
+ clone clone_p_quantum-metadata-agent p_quantum-metadata-agent \
+ meta interleave="true" is-managed="true"
+ clone clone_p_quantum-openvswitch-agent p_quantum-openvswitch-agent \
+ meta interleave="true"
+
+And ties them with pacemaker colocation resource::
+
+ colocation dhcp-with-metadata inf: p_quantum-dhcp-agent \
+ clone_p_quantum-metadata-agent
+ colocation dhcp-with-ovs inf: p_quantum-dhcp-agent \
+ clone_p_quantum-openvswitch-agent
+ colocation dhcp-without-l3 -100: p_quantum-dhcp-agent p_quantum-l3-agent
+ colocation l3-with-metadata inf: p_quantum-l3-agent clone_p_quantum-metadata-agent
+ colocation l3-with-ovs inf: p_quantum-l3-agent clone_p_quantum-openvswitch-agent
+ order dhcp-after-metadata inf: clone_p_quantum-metadata-agent p_quantum-dhcp-agent
+ order dhcp-after-ovs inf: clone_p_quantum-openvswitch-agent p_quantum-dhcp-agent
+ order l3-after-metadata inf: clone_p_quantum-metadata-agent p_quantum-l3-agent
+ order l3-after-ovs inf: clone_p_quantum-openvswitch-agent p_quantum-l3-agent
+
+.. index:: HA with Pacemaker and Corosync; How To Troubleshoot Corosync/Pacemaker
+
+How To Troubleshoot Corosync/Pacemaker
+--------------------------------------
+
+Pacemaker and Corosync come with several CLI utilities that can help you
+troubleshoot and understand what is going on.
+
+crm - Cluster Resource Manager
+++++++++++++++++++++++++++++++
+
+This is the main pacemaker utility it shows you state of pacemaker cluster.
+Several most popular commands that you can use to understand whether your
+cluster is consistent:
+
+**crm status**
+
+This command shows you the main information about pacemaker cluster and state of
+resources being managed::
+
+ crm(live)# status
+ ============
+ Last updated: Tue May 14 15:13:47 2013
+ Last change: Mon May 13 18:36:56 2013 via cibadmin on fuel-controller-01
+ Stack: openais
+ Current DC: fuel-controller-01 - partition with quorum
+ Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
+ 5 Nodes configured, 5 expected votes
+ 3 Resources configured.
+ ============
+
+ Online: [ fuel-controller-01 fuel-controller-02 fuel-controller-03
+ fuel-controller-04 fuel-controller-05 ]
+
+ p_quantum-plugin-openvswitch-agent (ocf::pacemaker:quantum-agent-ovs): Started fuel-controller-01
+ p_quantum-dhcp-agent (ocf::pacemaker:quantum-agent-dhcp): Started fuel-controller-01
+ p_quantum-l3-agent (ocf::pacemaker:quantum-agent-l3): Started fuel-controller-01
+
+**crm(live)# resource**
+
+Here you can enter resource-specific commands::
+
+ crm(live)resource# status`
+
+ p_quantum-plugin-openvswitch-agent (ocf::pacemaker:quantum-agent-ovs) Started
+ p_quantum-dhcp-agent (ocf::pacemaker:quantum-agent-dhcp) Started
+ p_quantum-l3-agent (ocf::pacemaker:quantum-agent-l3) Started
+
+**crm(live)resource# start|restart|stop|cleanup **
+
+These commands let you correspondingly start, stop, restart resources.
+
+**cleanup**
+
+Cleanup command cleans resources state on the nodes in case of their failure or
+unexpected operation, e.g. some residuals of SysVInit operation on resource, in
+which case pacemaker will manage it by itself, thus deciding in which node to
+run the resource.
+
+E.g.::
+
+ 3 Nodes configured, 3 expected votes
+ 3 Resources configured.
+ ============
+
+ 3 Nodes configured, 3 expected votes
+ 16 Resources configured.
+
+
+ Online: [ controller-01 controller-02 controller-03 ]
+
+ vip__management_old (ocf::heartbeat:IPaddr2): Started controller-01
+ vip__public_old (ocf::heartbeat:IPaddr2): Started controller-02
+ Clone Set: clone_p_haproxy [p_haproxy]
+ Started: [ controller-01 controller-02 controller-03 ]
+ Clone Set: clone_p_mysql [p_mysql]
+ Started: [ controller-01 controller-02 controller-03 ]
+ Clone Set: clone_p_quantum-openvswitch-agent [p_quantum-openvswitch-agent]
+ Started: [ controller-01 controller-02 controller-03 ]
+ Clone Set: clone_p_quantum-metadata-agent [p_quantum-metadata-agent]
+ Started: [ controller-01 controller-02 controller-03 ]
+ p_quantum-dhcp-agent (ocf::mirantis:quantum-agent-dhcp): Started controller-01
+ p_quantum-l3-agent (ocf::mirantis:quantum-agent-l3): Started controller-03
+
+In this case there were residual OpenStack agent processes that were started by
+pacemaker in case of network failure and cluster partitioning. After the
+restoration of connectivity pacemaker saw these duplicate resources running on
+different nodes. You can let it clean up this situation automatically or, if you
+do not want to wait, cleanup them manually.
+
+.. seealso::
+
+ crm interactive help and documentation resources for Pacemaker
+ (e.g. http://doc.opensuse.org/products/draft/SLE-HA/SLE-ha-guide_sd_draft/cha.ha.manual_config.html).
+
+In some network scenarios one can get cluster split into several parts and
+``crm status`` showing something like this::
+
+ On ctrl1
+ ============
+ ….
+ Online: [ ctrl1 ]
+
+ On ctrl2
+ ============
+ ….
+ Online: [ ctrl2 ]
+
+ On ctrl3
+ ============
+ ….
+ Online: [ ctrl3 ]
+
+You can troubleshoot this by checking corosync connectivity between nodes.
+There are several points:
+
+1) Multicast should be enabled in the network, IP address configured as
+ multicast should not be filtered, mcastport and mcasport - 1 udp ports should
+ be accepted on management network between controllers
+
+2) corosync should start after network interfaces are configured
+
+3) bindnetaddr should be in the management network or at least in the same
+ multicast reachable segment
+
+You can check this in output of ``ip maddr show``:
+
+.. code-block:: none
+ :emphasize-lines: 1,8
+
+ 5: br-mgmt
+ link 33:33:00:00:00:01
+ link 01:00:5e:00:00:01
+ link 33:33:ff:a3:e2:57
+ link 01:00:5e:01:01:02
+ link 01:00:5e:00:00:12
+ inet 224.0.0.18
+ inet 239.1.1.2
+ inet 224.0.0.1
+ inet6 ff02::1:ffa3:e257
+ inet6 ff02::1
+
+**corosync-objctl**
+
+This command is used to get/set runtime corosync configuration values including
+status of corosync redundant ring members::
+
+ runtime.totem.pg.mrp.srp.members.134245130.ip=r(0) ip(10.107.0.8)
+ runtime.totem.pg.mrp.srp.members.134245130.join_count=1
+ ...
+ runtime.totem.pg.mrp.srp.members.201353994.ip=r(0) ip(10.107.0.12)
+ runtime.totem.pg.mrp.srp.members.201353994.join_count=1
+ runtime.totem.pg.mrp.srp.members.201353994.status=joined
+
+
+If IP of the node is 127.0.0.1 it means that corosync started when only loopback
+interfaces was available and bound to it.
+
+If there is only one IP in members list that means there is corosync connectivity
+issue because the node does not see the other ones. The same stays for the case
+when members list is incomplete.
+
+.. index:: HA with Pacemaker and Corosync; How To smoke test HA
+
+How To Smoke Test HA
+--------------------
+
+To test if Quantum HA is working, simply shut down the node hosting, e.g. Quantum
+agents (either gracefully or hardly). You should see agents start on the other node::
+
+
+ # crm status
+
+ Online: [ fuel-controller-02 fuel-controller-03 fuel-controller-04 fuel-controller-05 ]
+ OFFLINE: [ fuel-controller-01 ]
+
+ p_quantum-plugin-openvswitch-agent (ocf::pacemaker:quantum-agent-ovs): Started fuel-controller-02
+ p_quantum-dhcp-agent (ocf::pacemaker:quantum-agent-dhcp): Started fuel-controller-02
+ p_quantum-l3-agent (ocf::pacemaker:quantum-agent-l3): Started fuel-controller-02
+
+and see corresponding Quantum interfaces on the new Quantum node::
+
+ # ip link show
+
+ 11: tap7b4ded0e-cb: mtu 1500 qdisc
+ 12: qr-829736b7-34: mtu 1500 qdisc
+ 13: qg-814b8c84-8f: mtu 1500 qdisc
+
+You can also check ``ovs-vsctl show output`` to see that all corresponding
+tunnels/bridges/interfaces are created and connected properly::
+
+ ce754a73-a1c4-4099-b51b-8b839f10291c
+ Bridge br-mgmt
+ Port br-mgmt
+ Interface br-mgmt
+ type: internal
+ Port "eth1"
+ Interface "eth1"
+ Bridge br-ex
+ Port br-ex
+ Interface br-ex
+ type: internal
+ Port "eth0"
+ Interface "eth0"
+ Port "qg-814b8c84-8f"
+ Interface "qg-814b8c84-8f"
+ type: internal
+ Bridge br-int
+ Port patch-tun
+ Interface patch-tun
+ type: patch
+ options: {peer=patch-int}
+ Port br-int
+ Interface br-int
+ type: internal
+ Port "tap7b4ded0e-cb"
+ tag: 1
+ Interface "tap7b4ded0e-cb"
+ type: internal
+ Port "qr-829736b7-34"
+ tag: 1
+ Interface "qr-829736b7-34"
+ type: internal
+ Bridge br-tun
+ Port "gre-1"
+ Interface "gre-1"
+ type: gre
+ options: {in_key=flow, out_key=flow, remote_ip="10.107.0.8"}
+ Port "gre-2"
+ Interface "gre-2"
+ type: gre
+ options: {in_key=flow, out_key=flow, remote_ip="10.107.0.5"}
+ Port patch-int
+ Interface patch-int
+ type: patch
+ options: {peer=patch-tun}
+ Port "gre-3"
+ Interface "gre-3"
+ type: gre
+ options: {in_key=flow, out_key=flow, remote_ip="10.107.0.6"}
+ Port "gre-4"
+ Interface "gre-4"
+ type: gre
+ options: {in_key=flow, out_key=flow, remote_ip="10.107.0.7"}
+ Port br-tun
+ Interface br-tun
+ type: internal
+ ovs_version: "1.4.0+build0"
+
\ No newline at end of file
diff --git a/pages/release-notes/v3-1-grizzly.rst b/pages/release-notes/v3-1-grizzly.rst
index 94bccde34..d75612f65 100644
--- a/pages/release-notes/v3-1-grizzly.rst
+++ b/pages/release-notes/v3-1-grizzly.rst
@@ -8,7 +8,7 @@ v3.1-grizzly
New Features in Fuel 3.1
-------------------------
-.. contents:: :local:
+.. contents :local:
* Combined Fuel library and Fuel Web products
* Option to deploy Red Hat Enterprise Linux® OpenStack® Platform
@@ -18,11 +18,11 @@ New Features in Fuel 3.1
* Improved High Availability resiliency
* Horizon password entry can be hidden
-Fuel 3.1 with Integrated graphical and command line controls
+Fuel 3.1 with Integrated Graphical and Command Line Controls
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
In earlier releases, Fuel was distributed as two packages – “Fuel Web” for
-graphical workflow, and “Fuel library” for command-line based manipulation.
+graphical workflow, and “Fuel Library” for command-line based manipulation.
Starting with this 3.1 release, we’ve integrated these two capabilities into
a single offering, referred to simply as Fuel. If you used Fuel Web, you’ll
see that capability along with its latest improvements to that capability in
@@ -32,7 +32,7 @@ configurations. Advanced users with more complex environmental needs can
still get command-line access to the underlying deployment engine (aka “Fuel
Library”).
-Option to deploy Red Hat Enterprise Linux® OpenStack® Platform
+Option to Deploy Red Hat Enterprise Linux® OpenStack® Platform
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Mirantis Fuel now includes the ability to deploy the Red Hat Enterprise
@@ -44,8 +44,8 @@ nodes or installing the Red Hat provided OpenStack distribution onto Red Hat
Enterprise Linux powered nodes.
.. note:: A Red Hat subscription is required to download and deploy Red Hat
- Enterprise Linux OpenStack Platform.
-
+ Enterprise Linux OpenStack Platform.
+
Mirantis OpenStack Health Check
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -78,7 +78,7 @@ Improved High Availability resiliency
To improve the resiliency of the Mirantis OpenStack High Availability
reference architecture, Fuel now deploys all HA services under Pacemaker, a
-scalable cluster resource manager developed by Clusterlabs. Additional
+scalable cluster resource manager developed by ClusterLabs. Additional
options in the Fuel Library have also been added to Corosync to enable more
granular tuning.
diff --git a/pdf_index.rst b/pdf_index.rst
index 29669e37b..4c98e8265 100644
--- a/pdf_index.rst
+++ b/pdf_index.rst
@@ -1,81 +1,29 @@
.. header::
- .. cssclass:: header-table
-
- +-------------------------------------+-----------------------------------+
- | Fuel™ for Openstack v3.1 | .. cssclass:: right|
- | | |
- | User Guide | ###Section### |
- +-------------------------------------+-----------------------------------+
+ .. cssclass:: header-table
+
+ +-------------------------------------+-----------------------------------+
+ | Fuel™ for Openstack v3.1 | .. cssclass:: right|
+ | | |
+ | User Guide | ###Section### |
+ +-------------------------------------+-----------------------------------+
.. footer::
- .. cssclass:: footer-table
-
- +--------------------------+----------------------+
- | | .. cssclass:: right|
- | | |
- | ©2013, Mirantis Inc. | Page ###Page### |
- +--------------------------+----------------------+
+ .. cssclass:: footer-table
+
+ +--------------------------+----------------------+
+ | | .. cssclass:: right|
+ | | |
+ | ©2013, Mirantis Inc. | Page ###Page### |
+ +--------------------------+----------------------+
.. raw:: pdf
PageBreak oneColumn
-.. include:: index.rst
-
-.. raw:: pdf
-
- PageBreak
-
-.. include:: copyright.rst
-
-.. raw:: pdf
-
- PageBreak
-
.. contents:: Table of Contents
- :depth: 2
+ :depth: 2
-.. raw:: pdf
-
- PageBreak
-
-.. include:: 0020-about-fuel.rst
-
-.. raw:: pdf
-
- PageBreak
-
-.. include:: 0030-release-notes.rst
-
-.. raw:: pdf
-
- PageBreak
-
-.. include:: 0040-reference-architecture.rst
-
-.. raw:: pdf
-
- PageBreak
-
-.. include:: 0045-installation-fuel-ui.rst
-
-.. raw:: pdf
-
- PageBreak
-
-.. include:: 0050-installation-fuel-cli.rst
-
-.. raw:: pdf
-
- PageBreak
-
-.. include:: 0055-production-considerations.rst
-
-.. raw:: pdf
-
- PageBreak
-
-.. include:: 0060-frequently-asked-questions.rst
+.. include:: contents.rst
diff --git a/rn_index.rst b/rn_index.rst
index 499199fac..9fb7172d5 100644
--- a/rn_index.rst
+++ b/rn_index.rst
@@ -1,3 +1,5 @@
+:orphan:
+
.. header::