Modify heat-engine's description in developer docs

Closes-Bug: #1462888

Change-Id: I1fb034d69d899b67db2706a3c192fcc8e40f4aee

doc/source/architecture.rst

@@ -62,6 +62,6 @@ The heat-api-cfn component provides an AWS Query API that is compatible with AWS
 heat-engine
 -----------
 
-The heat engine's main responsibility is to orchestrate the launching of templates and provide events back to the API consumer.
+The heat-engine's main responsibility is to orchestrate the launching of templates and provide events back to the API consumer.
 
 The templates integrate well with .. _Puppet: https://s3.amazonaws.com/cloudformation-examples/IntegratingAWSCloudFormationWithPuppet.pdf and .. _Chef: http://www.full360.com/2011/02/27/integrating-aws-cloudformation-and-chef.html

doc/source/man/heat-engine.rst

@@ -10,11 +10,12 @@ SYNOPSIS
 
 DESCRIPTION
 ===========
-Heat is the heat project server with an internal api called by the heat-api.
+heat-engine is the heat project server with an internal RPC api called
+by the heat-api server.
 
 INVENTORY
 =========
-The heat engine does all the orchestration work and is the layer in which
+The heat-engine does all the orchestration work and is the layer in which
 the resource integration is implemented.
 
 OPTIONS
@@ -29,7 +30,7 @@ OPTIONS
 
   Path to a config directory to pull .conf files from. This file set is
   sorted, so as to provide a predictable parse order if individual options are
-  over-ridden. The set is parsed after the file(s), if any, specified via 
+  over-ridden. The set is parsed after the file(s), if any, specified via
   --config-file, hence over-ridden options in the directory take precedence.
 
 .. cmdoption:: --version

doc/source/man/heat-manage.rst

@@ -42,7 +42,7 @@ Heat Db version
 
 ``heat-manage service list``
 
-    Shows details for all currently running heat engines.
+    Shows details for all currently running heat-engines.
 
 ``heat-manage --version``
 

doc/source/pluginguide.rst

@@ -552,7 +552,7 @@ the requirements for a candidate resource to be considered for inclusion:
 - Must have its dependencies listed in OpenStack's ``global-requirements.txt``
   file, or else it should be able to conditionally disable itself when there
   are missing dependencies, without crashing or otherwise affecting the normal
-  operation of the Heat engine service.
+  operation of the heat-engine service.
 - The resource's support status flag must be set to ``UNSUPPORTED``, to
   indicate that the Heat team is not responsible for supporting this resource.
 - The code must be of comparable quality to official resources. The Heat team
@@ -564,4 +564,4 @@ but you still think it can be useful to other users, you are encouraged to
 host it on your own repository and share it as a regular Python installable
 package. You can find example resource plug-ins that have all the required
 packaging files in the ``contrib`` directory of the official Heat git
-repository.
+repository.

doc/source/scale_deployment.rst

@@ -51,7 +51,7 @@ Basic 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] -|

doc/source/template_guide/environment.rst

@@ -54,7 +54,7 @@ operator can add additional environment entries.
 
 The cloud operator can add to the global environment
 by putting environment files in a configurable directory wherever
-the heat engine runs.  The configuration variable is named
+the heat-engine runs.  The configuration variable is named
 "environment_dir" is found in the "[DEFAULT]" section
 of "/etc/heat/heat.conf".  The default for that directory is
 "/etc/heat/environment.d".  Its contents are combined in whatever

doc/source/template_guide/hot_spec.rst

@@ -463,7 +463,7 @@ The syntax of the custom_constraint constraint is:
 
 The *name* specifies the concrete type of custom constraint. It corresponds to
 the name under which the respective validation plugin has been registered with
-the Heat engine.
+the heat-engine.
 
 For example: