openstack/fuel-docs
Code Issues Proposed changes

Merge "Tiny little last-minute changes"

Browse Source
This commit is contained in:
Jenkins 2014-09-18 05:26:40 +00:00 committed by Gerrit Code Review
commit 2555f7e34a
7 changed files with 24 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
pages/operations/8100-backup.rst
View File

@ -3,7 +3,7 @@
.. _Backup_and_restore_Fuel_Master:
HowTo: Backup and restore Fuel Master
-------------------------------------
=====================================
Because the Fuel Master itself is not available with high availability,
it is strongly recommended to create a backup after each deployment. This
@ -21,10 +21,12 @@ during the backup process, causing no impact for any deployed or
bootstrapped nodes.
In order to back up the Fuel Master, you need to meet these requirements:
* No deployment tasks are currently running
* You have at least 11GB free disk space
The backup contains the following items:
* All docker containers (including Fuel DB)
* PXE deployment configuration
* All OpenStack environment configurations
@ -33,13 +35,16 @@ The backup contains the following items:
* Puppet manifests
Items not backed up include logs and host network configuration.
If preserving log data is important, back up the /var/log directory
separately. This could be done by using *scp* to transfer /var/log to another
If preserving log data is important, back up the */var/log* directory
separately. This could be done by using *scp* to transfer */var/log* to another
host. Network configuration needs to be done manually via Fuel Setup if you
reinstall your Fuel Master before restoring it.
Running the backup
------------------
To start a backup, run **dockerctl backup**. Optionally, you can specify a
path for backup. The default path is **/var/backup/fuel**.
path for backup. The default path is */var/backup/fuel*.
This process takes approximately 30 minutes
and is dependent on the performance of your hardware.
After the backup is done, you may want to copy the backup to
@ -54,9 +59,10 @@ Restoring Fuel Master
The restore is quite similar to the backup process.
This process can be run any time after installing a Fuel Master
node. Before starting a restore operation, ensure the following:
* The Fuel version is the same release as the backup
* There are no deployments running
* At least 11GB free space in /var
* At least 11GB free space in */var*
If you reinstall your Fuel Master host, you need to configure your network

6
pages/terminology/a/amqp.rst
View File

@ -4,7 +4,6 @@ AMQP (Advanced Message Queuing Protocol)
----------------------------------------
AMQP is an international standard for message-oriented middleware.
standard for details.
AMQP is a wire-level protocol,
meaning that it describes the format of the data that is transmitted,
so any tool that is AMQP compliant can generate and interpret messages
@ -13,12 +12,13 @@ for any other AMQP compliant tool.
Mirantis OpenStack and Fuel use :ref:`rabbitmq-term`
as the AMQP compliant messaging interface.
See:
For more information:
- The RabbitMQ site provides a nice
`tutorial about AMQP <https://www.rabbitmq.com/tutorials/amqp-concepts.html>`_.
-`AMQP and Nova <http://docs.openstack.org/developer/nova/devref/rpc.html>`_.
- For an architectural overview,
see `AMQP and Nova <http://docs.openstack.org/developer/nova/devref/rpc.html>`_.
- `ISO/IEC 19494
<http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=64955>`_

4
pages/terminology/a/availability-zone.rst
View File

@ -5,13 +5,13 @@ Availability Zone
-----------------
An Availability Zone is a name given to a
"ref"`host aggregate<host-aggregates-term>`.
:ref:`host aggregate<host-aggregates-term>`.
An Availability Zone can be used to segregate your cloud environment;
for example, to identify hosts that are equipped for
heavy computational activities
or that have some sort of specialized equipment attached to them.
Users can specify an Availability Zone
when launching an instance in Horizon;
the :ref:`scheduler-term` then uses the Availability Zone
the :ref:`Nova scheduler <scheduler-term>` then uses the Availability Zone
as a criteria when allocating an instance to a node.

4
pages/terminology/h/ha.rst
View File

@ -12,7 +12,7 @@ for more information about the OpenStack implementation.
When you create an OpenStack environment with Fuel,
you are asked to choose either an HA or non-HA deployment mode
on the :ref:`mode-ha-ug` screen.
Before Mirantis OpenStack 5.0,
Before Mirantis OpenStack 5.1,
different internal architectures were used for the two modes;
if you deployed a non-HA environment,
you had to redeploy the environment to convert it to HA.
@ -41,7 +41,7 @@ see :ref:`Multi-node_HA`.
The multi-node mode,
previously used to deploy an environment with only one controller,
is retained as a legacy option in Mirantis OpenStack for 5.0
is retained as a legacy option in Mirantis OpenStack for 5.1
but it is not recommended for deploying new environments;
we expect to remove this option in a future release.

3
pages/terminology/h/hadoop.rst
View File

@ -5,6 +5,7 @@ Hadoop (Apache Hadoop)
The Apache Hadoop project develops software for processing "Big Data".
See the `Apache Hadoop homepage <http://hadoop.apache.org/>`_.
The OpenStack Sahara project provides extensions to OpenStack
The OpenStack :ref:`Sahara<sahara-term>` project
provides extensions to OpenStack
that enable it to run Hadoop clusters.

3
pages/terminology/h/host-aggregates.rst
View File

@ -1,5 +1,6 @@
.. :host-aggregates-term:
.. _host-aggregates-term:
Host Aggregates
---------------

3
pages/terminology/s/sahara.rst
View File

@ -14,9 +14,10 @@ follow the instructions in
See:
- :ref:`sahara-plan` discusses considerations
for planning for Sahara.
- :ref:`sahara-install` gives instructions for installing
Sahara and running Apache Hadoop in your OpenStack environment.
- :ref:`sahara-plan` discusses
- `Sahara wiki page <https://wiki.openstack.org/wiki/Sahara>`_
for more information about Sahara,
including a link to its documentation.