openstack/openstack-manuals
Code Issues Proposed changes

[arch-design] Change modules to services

Browse Source 
At now, Orchestration and Telemetry are services, not modules.
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

Change-Id: I5e2bba8498c66f50e2435d298bf3eb7c7b66c3fe
This commit is contained in:
KATO Tomoyuki
2015-10-28 09:47:49 +09:00
parent 08634ad62e
commit db00e94bcf
14 changed files with 27 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
doc/arch-design/ch_legal-security-requirements.xml
View File

@@ -247,7 +247,7 @@
facilitates using DNS as a mechanism for determining which
region would be selected for certain applications.</para>
<para>Another useful tool for managing a multi-site installation
is OpenStack Orchestration (heat). The Orchestration module
is Orchestration (heat). The Orchestration service
allows the use of templates to define a set of instances to
be launched together or for scaling existing sets. It can
set up matching or differentiated groupings based on

4
doc/arch-design/compute_focus/section_architecture_compute_focus.xml
View File

@@ -166,7 +166,7 @@
<title>OpenStack components</title>
<para>The selection of OpenStack components is important.
There are certain components that are required, for example the compute
and image services, but others, such as the Orchestration module, may not
and image services, but others, such as the Orchestration service, may not
be present.</para>
<para>For a compute-focused OpenStack design architecture, the
following components may be present:</para>
@@ -200,7 +200,7 @@
</note>
<para>The exclusion of certain OpenStack components might also limit the
functionality of other components. If a design includes
the Orchestration module but excludes the Telemetry module, then
the Orchestration service but excludes the Telemetry service, then
the design cannot take advantage of Orchestration's auto
scaling functionality as this relies on information from Telemetry.</para>
</section>

2
doc/arch-design/compute_focus/section_prescriptive_examples_compute_focus.xml
View File

@@ -134,7 +134,7 @@
<section xml:id="monitoring">
<title>Monitoring</title>
<para>CERN does not require direct billing, but uses the Telemetry module
<para>CERN does not require direct billing, but uses the Telemetry service
to perform metering for the purposes of adjusting
project quotas. CERN uses a sharded, replicated, MongoDB back-end.
To spread API load, CERN deploys instances of the nova-api service

13
doc/arch-design/compute_focus/section_tech_considerations_compute_focus.xml
View File

@@ -235,23 +235,22 @@
<para>Also consider several specialized components:</para>
<itemizedlist>
<listitem>
<para><glossterm>Orchestration</glossterm> module
(<glossterm>heat</glossterm>)</para>
<para><glossterm>Orchestration</glossterm> (heat)</para>
<para>Given the nature of the
applications involved in this scenario, these are heavily
automated deployments. Making use of Orchestration is highly
beneficial in this case. You can script the deployment of a
batch of instances and the running of tests, but it
makes sense to use the Orchestration module
makes sense to use the Orchestration service
to handle all these actions.</para>
</listitem>
<listitem>
<para>Telemetry module (ceilometer)</para>
<para>Telemetry (ceilometer)</para>
<para>Telemetry and the alarms it generates support autoscaling
of instances using Orchestration. Users that are not using the
Orchestration module do not need to deploy the Telemetry module and
may choose to use external solutions to fulfill their
metering and monitoring requirements.</para>
Orchestration service do not need to deploy the Telemetry
service and may choose to use external solutions to fulfill
their metering and monitoring requirements.</para>
</listitem>
<listitem>
<para>OpenStack Block Storage (cinder)</para>

2
doc/arch-design/generalpurpose/section_prescriptive_example_general_purpose.xml
View File

@@ -87,7 +87,7 @@
is advised.
</para>
</note>
<para>Leveraging Orchestration and Telemetry modules is also a potential issue when
<para>Leveraging Orchestration and Telemetry services is also a potential issue when
providing auto-scaling, orchestrated web application environments.
Defining the web applications in <glossterm
baseform="Heat Orchestration Template (HOT)">Heat Orchestration Templates (HOT)</glossterm>

2
doc/arch-design/generalpurpose/section_tech_considerations_general_purpose.xml
View File

@@ -436,7 +436,7 @@
(<glossterm>horizon</glossterm>)</para>
</listitem>
<listitem>
<para><glossterm>Telemetry</glossterm> module
<para><glossterm>Telemetry</glossterm>
(<glossterm>ceilometer</glossterm>)</para>
</listitem>
</itemizedlist>

2
doc/arch-design/hybrid/section_architecture_hybrid.xml
View File

@@ -71,7 +71,7 @@
OpenStack supports MySQL as a service but not NoSQL
databases in production. To move from or run
alongside AWS, a NoSQL workload must use an automation
tool, such as the Orchestration module (heat), to
tool, such as the Orchestration service (heat), to
recreate the NoSQL database on top of OpenStack.
</para>
</listitem>

2
doc/arch-design/hybrid/section_prescriptive_examples_hybrid.xml
View File

@@ -53,7 +53,7 @@
Telemetry services handle, manage, and control workloads.</para>
<para>The private OpenStack cloud has at least one
controller and at least one compute node. It includes
metering using the Telemetry module. The Telemetry module
metering using the Telemetry service. The Telemetry service
captures the load increase and the CMP processes the information.
If there is available capacity, the CMP uses the
OpenStack API to call the Orchestration service. This creates

8
doc/arch-design/hybrid/section_tech_considerations_hybrid.xml
View File

@@ -87,7 +87,7 @@
stressing it is undesirable. A cost model of various scenarios and
consideration of internal priorities helps with this decision. To
improve efficiency, automate these decisions when possible.</para>
<para>The Telemetry module (ceilometer) provides information on the usage
<para>The Telemetry service (ceilometer) provides information on the usage
of various OpenStack components. Note the following:</para>
<itemizedlist>
<listitem>
@@ -118,7 +118,7 @@
cloud can most efficiently run which types of workloads.</para>
<para>As with utilization, native OpenStack tools help improve performance.
For example, you can use Telemetry to measure performance and the
Orchestration module (heat) to react to changes in demand.</para>
Orchestration service (heat) to react to changes in demand.</para>
<note>
<para>Orchestration requires special client configurations to integrate
with Amazon Web Services. For other types of clouds, use CMP
@@ -150,14 +150,14 @@
</listitem>
</varlistentry>
<varlistentry>
<term>Telemetry module (ceilometer)</term>
<term>Telemetry (ceilometer)</term>
<listitem>
<para>Use of Telemetry depends, in large part, on what the other
parts of the cloud you are using.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Orchestration module (heat)</term>
<term>Orchestration (heat)</term>
<listitem>
<para>Orchestration can be a valuable tool in orchestrating tasks a
CMP decides are necessary in an OpenStack-based cloud.</para>

2
doc/arch-design/multi_site/section_prescriptive_examples_multi_site.xml
View File

@@ -112,7 +112,7 @@
<para>OpenStack Controller services running, Networking,
dashboard, Block Storage and Compute running locally in
each of the three regions. Identity service, Orchestration
module, Telemetry module, Image service and
service, Telemetry service, Image service and
Object Storage service can be installed centrally, with
nodes in each of the region providing a redundant
OpenStack Controller plane throughout the globe.</para>

2
doc/arch-design/multi_site/section_tech_considerations_multi_site.xml
View File

@@ -164,7 +164,7 @@
facilitates using DNS as a mechanism for determining which
region will be selected for certain applications.</para>
<para>Another useful tool for managing a multi-site installation
is Orchestration (heat). The Orchestration module allows the
is Orchestration (heat). The Orchestration service allows the
use of templates to define a set of instances to be launched
together or for scaling existing sets. It can also be used to
set up matching or differentiated groupings based on

4
doc/arch-design/network_focus/section_architecture_network_focus.xml
View File

@@ -47,12 +47,12 @@
to outside systems.
</para>
<para>Interaction with orchestration services is inevitable in
larger-scale deployments. The Orchestration module is capable of
larger-scale deployments. The Orchestration service is capable of
allocating network resource defined in templates to map to tenant
networks and for port creation, as well as allocating floating IPs.
If there is a requirement to define and manage network resources when
using orchestration, we recommend that the design include the
Orchestration module to meet the demands of users.</para>
Orchestration service to meet the demands of users.</para>
<section xml:id="design-impacts">
<title>Design impacts</title>
<para>A wide variety of factors can affect a network-focused OpenStack

8
doc/arch-design/network_focus/section_prescriptive_examples_network_focus.xml
View File

@@ -60,17 +60,17 @@
<para>OpenStack Object Storage</para>
</listitem>
<listitem>
<para>Orchestration module</para>
<para>Orchestration service</para>
</listitem>
<listitem>
<para>Telemetry module</para>
<para>Telemetry service</para>
</listitem>
</itemizedlist>
<para>Beyond the normal Identity, Compute, Image service, and Object
Storage components, we recommend the Orchestration module
Storage components, we recommend the Orchestration service
component to handle the proper scaling of workloads to adjust to
demand. Due to the requirement for auto-scaling,
the design includes the Telemetry module. Web services
the design includes the Telemetry service. Web services
tend to be bursty in load, have very defined peak and valley
usage patterns and, as a result, benefit from automatic scaling
of instances based upon traffic. At a network level, a split

2
doc/arch-design/storage_focus/section_architecture_storage_focus.xml
View File

@@ -463,7 +463,7 @@
components that are always present
(Compute and Image service, for example), there are other services
that may not be required. As an example, a certain design
may not require the Orchestration module. Omitting Orchestration would
may not require the Orchestration service. Omitting Orchestration would
not typically have a significant impact on the overall design,
however, if the architecture uses a replacement for OpenStack Object
Storage for its storage component, this could potentially have