changed heat dev docs to comply with conventions

With the incorporation of many projects within OpenStack, it's very important to
use standards in the documentation This is important for formalization as well
as consistency
the proper usage is: heat or Orchestration or Orchestration module
heat should not be capitalized
https://wiki.openstack.org/wiki/Documentation/Conventions

Change-Id: Ia8d7f1429f877e4c88fc9b210948b63443376ba0
This commit is contained in:
Shilla Saebi 2015-04-24 22:03:07 -04:00
parent 23e10121b0
commit 47ea20b8ea
5 changed files with 20 additions and 20 deletions

View File

@ -1,5 +1,5 @@
====
HEAT
Heat
====
Heat is a service to orchestrate multiple composite cloud applications using

View File

@ -24,7 +24,7 @@ Build the REST API reference manual:
cd api-ref
mvn clean generate-sources
Build the Heat admin guide:
Build the heat admin guide:
cd heat-admin
mvn clean generate-sources

View File

@ -11,22 +11,22 @@
License for the specific language governing permissions and limitations
under the License.
How to get Heat to work with a remote OpenStack.
How to get heat to work with a remote OpenStack.
================================================
Say you have a remote/public install of OpenStack and you want to use
a local install of Heat to talk to it. This can be handy when
a local install of heat to talk to it. This can be handy when
developing, as the remote OpenStack can be kept stable and is not
effected by changes made to the development machine.
So lets say you have 2 machines:
* “rock” ip == 192.168.1.88 (used for base OpenStack services)
* “hack” ip == 192.168.1.77 (used for Heat development)
* “hack” ip == 192.168.1.77 (used for heat development)
Install your OpenStack as normal on “rock”.
In this example "hack" is used as the devstack to install Heat on.
In this example "hack" is used as the devstack to install heat on.
The localrc looked like this::
HEAT_STANDALONE=True

View File

@ -33,7 +33,7 @@ This guide, using a devstack installation of OpenStack, assumes that:
1. You have configured devstack from `Single Machine Installation Guide
<http://devstack.org/guides/single-machine.html>`_;
2. You have set up Heat on devstack, as defined at `Heat and Devstack
2. You have set up heat on devstack, as defined at `heat and Devstack
<http://docs.openstack.org/developer/heat/getting_started/
on_devstack.html>`_;
3. You have installed `HAProxy <http://haproxy.1wt.eu>`_ on the devstack
@ -42,16 +42,16 @@ This guide, using a devstack installation of OpenStack, assumes that:
Architecture
============
This section shows the basic Heat architecture, the load balancing mechanism
This section shows the basic heat architecture, the load balancing mechanism
used and the target scaled out architecture.
Basic Architecture
------------------
The Heat architecture is as defined at `Heat Architecture
The heat architecture is as defined at `heat architecture
<http://docs.openstack.org/developer/heat/architecture.html>`_ and shown in the
diagram below, where we have a CLI that sends HTTP requests to the ReST and CFN
APIs, which in turn make calls using AMQP to the Heat engine.
APIs, which in turn make calls using AMQP to the heat engine.
::
|- [REST API] -|
@ -64,7 +64,7 @@ Load Balancing
As there is a need to use a load balancer mechanism between the multiple APIs
and the CLI, a proxy has to be deployed.
Because the Heat CLI and APIs communicate by exchanging HTTP requests and
Because the heat CLI and APIs communicate by exchanging HTTP requests and
responses, a `HAProxy <http://haproxy.1wt.eu>`_ HTTP load balancer server will
be deployed between them.
@ -79,7 +79,7 @@ distribute messages round-robin (RabbitMQ does this by default).
Target Architecture
-------------------
A scaled out Heat architecture is represented in the diagram below:
A scaled out heat architecture is represented in the diagram below:
::
|- [REST-API] -|
@ -102,8 +102,8 @@ Thus, a request sent from the CLI looks like:
Deploying Multiple APIs
=======================
In order to run a Heat component separately, you have to execute one of the
python scripts located at the *bin* directory of your Heat repository.
In order to run a heat component separately, you have to execute one of the
python scripts located at the *bin* directory of your heat repository.
These scripts take as argument a configuration file. When using devstack, the
configuration file is located at */etc/heat/heat.conf*. For instance, to start
@ -238,7 +238,7 @@ For this sample, consider that:
1. We have an architecture composed by 3 machines configured in a LAN, with
the addresses A: 10.0.0.1; B: 10.0.0.2; and C: 10.0.0.3;
2. The OpenStack devstack installation, including the Heat module, has been
2. The OpenStack devstack installation, including the heat module, has been
done in the machine A, as shown in the
:ref:`scale_deployment_assumptions` section.
@ -246,7 +246,7 @@ Target Architecture
^^^^^^^^^^^^^^^^^^^
At this moment, everything is running in a single devstack server. The next
subsections show how to deploy a scaling out Heat architecture by:
subsections show how to deploy a scaling out heat architecture by:
1. Running one ReST and one CFN API on the machines B and C;
2. Setting up the HAProxy server on the machine A.
@ -256,11 +256,11 @@ Running the API and Engine Services
For each machine, B and C, you must do the following steps:
1. Clone the Heat repository https://github.com/openstack/heat;
1. Clone the heat repository https://github.com/openstack/heat;
2. Create a local copy of the configuration file */etc/heat/heat.conf* from
the machine A;
3. Make required changes on the configuration file;
4. Enter the Heat local repository and run:
4. Enter the heat local repository and run:
::

View File

@ -17,8 +17,8 @@ cfn-json2yaml
Package lists
=============
Lists of Linux packages to install in order to successfully run Heat's
unit test suit on a clean new Linux distro.
Lists of Linux packages to install in order to successfully run heat's
unit test suit on a clean new Linux distribution.
test-requires-deb
list of DEB packages as of Ubuntu 14.04 Trusty