openstack/openstack-manuals
Code Issues Proposed changes

[user-guides] 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: I8a75914f3152c9839c3a1e33540d01154d056135
This commit is contained in:
KATO Tomoyuki 2015-10-28 10:42:25 +09:00
parent 760207b6b4
commit 4509221057
15 changed files with 57 additions and 57 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/admin-guide-cloud/source/baremetal.rst
View File

@ -22,7 +22,7 @@ enterprises and service providers.
System architecture
~~~~~~~~~~~~~~~~~~~
The Bare Metal module is composed of the following components:
The Bare Metal service is composed of the following components:
#. An admin-only RESTful API service, by which privileged users, such
as cloud operators and other services within the cloud control

2
doc/admin-guide-cloud/source/orchestration-introduction.rst
View File

@ -7,7 +7,7 @@ automatically configures and deploys resources in stacks. The deployments can
be simple, such as deploying WordPress on Ubuntu with an SQL back end. They can
also be complex, such as starting a group of servers that auto scale by
starting and stopping based on real-time CPU loading information from the
Telemetry module.
Telemetry service.
Orchestration stacks are defined with templates, which are non-procedural
documents that describe tasks in terms of resources, parameters, inputs,

6
doc/admin-guide-cloud/source/telemetry-alarms.rst
View File

@ -7,7 +7,7 @@ Alarms
Alarms provide user-oriented Monitoring-as-a-Service for resources
running on OpenStack. This type of monitoring ensures you can
automatically scale in or out a group of instances through the
Orchestration module, but you can also use alarms for general-purpose
Orchestration service, but you can also use alarms for general-purpose
awareness of your cloud resources' health.
These alarms follow a tri-state model:
@ -46,7 +46,7 @@ governed by:
Combination rule alarms
-----------------------
The Telemetry module also supports the concept of a meta-alarm, which
The Telemetry service also supports the concept of a meta-alarm, which
aggregates over the current state of a set of underlying basic alarms
combined via a logical operator (AND or OR).
@ -67,7 +67,7 @@ ID). At the other extreme, you could have widely dimensioned alarms
where this selection identifies many resources over which the
statistic is aggregated. For example all instances booted from a
particular image or all instances with matching user metadata (the
latter is how the Orchestration module identifies autoscaling
latter is how the Orchestration service identifies autoscaling
groups).
Alarm evaluation

2
doc/admin-guide-cloud/source/telemetry-best-practices.rst
View File

@ -8,7 +8,7 @@ into data collection and storage.
Data collection
---------------
#. The Telemetry module collects a continuously growing set of data. Not
#. The Telemetry service collects a continuously growing set of data. Not
all the data will be relevant for a cloud administrator to monitor.
- Based on your needs, you can edit the :file:`pipeline.yaml` configuration

36
doc/admin-guide-cloud/source/telemetry-data-collection.rst
View File

@ -38,7 +38,7 @@ system state in OpenStack. Several notifications carry information that
can be metered, like the CPU time of a VM instance created by OpenStack
Compute service.
The Telemetry module has a separate agent that is responsible for
The Telemetry service has a separate agent that is responsible for
consuming notifications, namely the notification agent. This component
is responsible for consuming from the message bus and transforming
notifications into events and measurement samples. Beginning in the Liberty
@ -51,7 +51,7 @@ persisting the data into the configured database back end.
The different OpenStack services emit several notifications about the
various types of events that happen in the system during normal
operation. Not all these notifications are consumed by the Telemetry
module, as the intention is only to capture the billable events and
service, as the intention is only to capture the billable events and
notifications that can be used for monitoring or profiling purposes. The
notification agent filters by the event type, that is contained by each
notification message. The following table contains the event types by
@ -113,7 +113,7 @@ each OpenStack service that are transformed to samples by Telemetry.
| | l3.meter | |
+--------------------+------------------------+-------------------------------+
| Orchestration | orchestration.stack\ | |
| module | .create.end | |
| service | .create.end | |
| | | |
| | orchestration.stack\ | |
| | .update.end | |
@ -201,7 +201,7 @@ notifications.
Polling
~~~~~~~
The Telemetry module is intended to store a complex picture of the
The Telemetry service is intended to store a complex picture of the
infrastructure. This goal requires additional information than what is
provided by the events and notifications published by each service. Some
information is not emitted directly, like resource usage of the VM
@ -272,7 +272,7 @@ The following services can be polled with this agent:
- Energy consumption meters via `Kwapi <https://launchpad.net/kwapi>`__
framework
To install and configure this service use the `Install the Telemetry module
To install and configure this service use the `Add the Telemetry service
<http://docs.openstack.org/liberty/install-guide-ubuntu/ceilometer.html>`__
section in the OpenStack Installation Guide.
@ -311,7 +311,7 @@ provides a different set of meters.
The list of collected meters can be found in :ref:`telemetry-compute-meters`.
The support column provides the information that which meter is available for
each hypervisor supported by the Telemetry module.
each hypervisor supported by the Telemetry service.
.. note::
@ -451,9 +451,9 @@ in the :file:`ceilometer.conf` configuration file.
Send samples to Telemetry
~~~~~~~~~~~~~~~~~~~~~~~~~
While most parts of the data collection in the Telemetry module are
While most parts of the data collection in the Telemetry service are
automated, Telemetry provides the possibility to submit samples via the
REST API to allow users to send custom samples into this module.
REST API to allow users to send custom samples into this service.
This option makes it possible to send any kind of samples without the
need of writing extra code lines or making configuration changes.
@ -862,12 +862,12 @@ Example configuration::
Meter definitions
-----------------
The Telemetry module collects a subset of the meters by filtering notifications
emitted by other OpenStack services. Starting with the Liberty release, you can
find the meter definitions in a separate configuration file, called
:file:`ceilometer/meter/data/meter.yaml`. This enables operators/administrators
to add new meters to Telemetry project by updating the :file:`meter.yaml`
file without any need for additional code changes.
The Telemetry service collects a subset of the meters by filtering
notifications emitted by other OpenStack services. Starting with the Liberty
release, you can find the meter definitions in a separate configuration file,
called :file:`ceilometer/meter/data/meter.yaml`. This enables
operators/administrators to add new meters to Telemetry project by updating
the :file:`meter.yaml` file without any need for additional code changes.
.. note::
@ -972,7 +972,7 @@ the following format::
This script outputs what volumes or snapshots were created, deleted, or
exists in a given period of time and some information about these
volumes or snapshots. Information about the existence and size of
volumes and snapshots is store in the Telemetry module. This data is
volumes and snapshots is store in the Telemetry service. This data is
also stored as an event which is the recommended usage as it provides
better indexing of data.
@ -985,7 +985,7 @@ example, every 5 minutes::
Storing samples
~~~~~~~~~~~~~~~
The Telemetry module has a separate service that is responsible for
The Telemetry service has a separate service that is responsible for
persisting the data that comes from the pollsters or is received as
notifications. The data can be stored in a file or a database back end,
for which the list of supported databases can be found in
@ -1051,7 +1051,7 @@ The level of support differs in case of the configured back end:
HTTP dispatcher
---------------
The Telemetry module supports sending samples to an external HTTP
The Telemetry service supports sending samples to an external HTTP
target. The samples are sent without any modification. To set this
option as the collector's target, the ``dispatcher`` has to be changed
to ``http`` in the :file:`ceilometer.conf` configuration file. For the list
@ -1069,7 +1069,7 @@ in the OpenStack Configuration Reference.
Gnocchi dispatcher
------------------
The Telemetry module supports sending the metering data to Gnocchi back end
The Telemetry service supports sending the metering data to Gnocchi back end
through the gnocchi dispatcher. To set this option as the target, change the
``dispatcher`` to ``gnocchi`` in the :file:`ceilometer.conf`
configuration file.

12
doc/admin-guide-cloud/source/telemetry-data-retrieval.rst
View File

@ -2,7 +2,7 @@
Data retrieval
==============
The Telemetry module offers several mechanisms from which the persisted
The Telemetry service offers several mechanisms from which the persisted
data can be accessed. As described in :ref:`telemetry-system-architecture` and
in :ref:`telemetry-data-collection`, the collected information can be stored in
one or more database back ends, which are hidden by the Telemetry RESTful API.
@ -16,7 +16,7 @@ one or more database back ends, which are hidden by the Telemetry RESTful API.
Telemetry v2 API
~~~~~~~~~~~~~~~~
The Telemetry module provides a RESTful API, from which the collected
The Telemetry service provides a RESTful API, from which the collected
samples and all the related information can be retrieved, like the list
of meters, alarm definitions and so forth.
@ -177,7 +177,7 @@ in a single API request.
Telemetry command line client and SDK
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Telemetry module provides a command line client, with which the
The Telemetry service provides a command line client, with which the
collected data is available just as the alarm definition and retrieval
options. The client uses the Telemetry RESTful API in order to execute
the requested operations.
@ -190,7 +190,7 @@ in the OpenStack Installation Guide.
.. note::
The Telemetry module captures the user-visible resource usage data.
The Telemetry service captures the user-visible resource usage data.
Therefore the database will not contain any data without the
existence of these resources, like VM images in the OpenStack Image
service.
@ -465,7 +465,7 @@ reference.
Publishers
~~~~~~~~~~
The Telemetry module provides several transport methods to forward the
The Telemetry service provides several transport methods to forward the
data collected to the ceilometer-collector service or to an external
system. The consumers of this data are widely different, like monitoring
systems, for which data loss is acceptable and billing systems, which
@ -478,7 +478,7 @@ storage through the message bus or to send it to one or more external
consumers. One chain can contain multiple publishers.
To solve the above mentioned problem, the notion of multi-publisher can
be configured for each datapoint within the Telemetry module, allowing
be configured for each datapoint within the Telemetry service, allowing
the same technical meter or event to be published multiple times to
multiple destinations, each potentially using a different transport.

12
doc/admin-guide-cloud/source/telemetry-events.rst
View File

@ -2,9 +2,9 @@
Events
======
In addition to meters, the Telemetry module collects events triggered
In addition to meters, the Telemetry service collects events triggered
within an OpenStack environment. This section provides a brief summary
of the events format in the Telemetry module.
of the events format in the Telemetry service.
While a sample represents a single, numeric datapoint within a
time-series, an event is a broader concept that represents the state of
@ -14,7 +14,7 @@ general, events represent any action made in the OpenStack system.
Event configuration
~~~~~~~~~~~~~~~~~~~
To enable the creation and storage of events in the Telemetry module
To enable the creation and storage of events in the Telemetry service
``store_events`` option needs to be set to ``True``. For further configuration
options, see the event section in the `OpenStack Configuration Reference
<http://docs.openstack.org/kilo/config-reference/content/ch_configuring-openstack-telemetry.html>`__.
@ -22,14 +22,14 @@ options, see the event section in the `OpenStack Configuration Reference
.. note::
It is advisable to set ``disable_non_metric_meters`` to ``True``
when enabling events in the Telemetry module. The Telemetry module
when enabling events in the Telemetry service. The Telemetry service
historically represented events as metering data, which may create
duplication of data if both events and non-metric meters are
enabled.
Event structure
~~~~~~~~~~~~~~~
Events captured by the Telemetry module are represented by five key
Events captured by the Telemetry service are represented by five key
attributes:
event\_type
@ -83,7 +83,7 @@ fields in the notification exist and are non-null.
.. note::
The default definition file included with the Telemetry module
The default definition file included with the Telemetry service
contains a list of known notifications and useful traits. The
mappings provided can be modified to include more or less data
according to user requirements.

14
doc/admin-guide-cloud/source/telemetry-measurements.rst
View File

@ -4,7 +4,7 @@
Measurements
============
The Telemetry module collects meters within an OpenStack deployment.
The Telemetry service collects meters within an OpenStack deployment.
This section provides a brief summary about meters format and origin and
also contains the list of available meters.
@ -71,11 +71,11 @@ under the ``[filter:ceilometer]`` section in ``proxy-server.conf`` under the
external and internal users.
Measurements are grouped by services which are polled by
Telemetry or emit notifications that this module consumes.
Telemetry or emit notifications that this service consumes.
.. note::
The Telemetry module supports storing notifications as events. This
The Telemetry service supports storing notifications as events. This
functionality was added later, therefore the list of meters still
contains existence type and other event related items. The proper
way of using Telemetry is to configure it to use the event store and
@ -373,7 +373,7 @@ The following meters are collected for OpenStack Compute:
ceilometer sample-list -m instance -q metadata.instance_type=<value>
The Telemetry module supports to create new meters by using
The Telemetry service supports to create new meters by using
transformers. For more details about transformers see
:ref:`telemetry-transformers`. Among the meters gathered from libvirt and
Hyper-V there are a few ones which are generated from other meters. The list of
@ -1245,9 +1245,9 @@ The following meters are collected for FWaaS:
| l.rule.update | | | | | |
+---------------+-------+---------+------------+-----------+------------------+
Orchestration module
~~~~~~~~~~~~~~~~~~~~
The following meters are collected for the Orchestration module:
Orchestration service
~~~~~~~~~~~~~~~~~~~~~
The following meters are collected for the Orchestration service:
+----------------+-------+------+----------+--------------+-------------------+
| Name | Type | Unit | Resource | Origin | Note |

8
doc/admin-guide-cloud/source/telemetry-system-architecture.rst
View File

@ -4,11 +4,11 @@
System architecture
===================
The Telemetry module uses an agent-based architecture. Several modules
The Telemetry service uses an agent-based architecture. Several modules
combine their responsibilities to collect data, store samples in a
database, or provide an API service for handling incoming requests.
The Telemetry module is built from the following agents and services:
The Telemetry service is built from the following agents and services:
ceilometer-api
Presents aggregated metering data to consumers (such as billing
@ -106,7 +106,7 @@ The list of supported database back ends:
Supported hypervisors
~~~~~~~~~~~~~~~~~~~~~
The Telemetry module collects information about the virtual machines,
The Telemetry service collects information about the virtual machines,
which requires close connection to the hypervisor that runs on the
compute hosts.
@ -168,7 +168,7 @@ external networking services:
Users, roles and tenants
~~~~~~~~~~~~~~~~~~~~~~~~
This module of OpenStack uses OpenStack Identity for authenticating and
This service of OpenStack uses OpenStack Identity for authenticating and
authorizing users. The required configuration options are listed in the
`Telemetry
section <http://docs.openstack.org/kilo/config-reference/content/ch_configuring-openstack-telemetry.html>`__

2
doc/admin-guide-cloud/source/telemetry-troubleshooting-guide.rst
View File

@ -4,7 +4,7 @@ Troubleshoot Telemetry
Logging in Telemetry
--------------------
The Telemetry module has similar log settings as the other OpenStack
The Telemetry service has similar log settings as the other OpenStack
services. Multiple options are available to change the target of
logging, the format of the log entries and the log levels.

8
doc/admin-guide-cloud/source/telemetry.rst
View File

@ -12,13 +12,13 @@ and billing solutions cannot be designed in a common module that
satisfies all. Providing users with measurements on cloud services is
required to meet the "measured service" definition of cloud computing.
The Telemetry module was originally designed to support billing
The Telemetry service was originally designed to support billing
systems for OpenStack cloud resources. This project only covers the
metering portion of the required processing for billing. This module
metering portion of the required processing for billing. This service
collects information about the system and stores it in the form of
samples in order to provide data about anything that can be billed.
In addition to system measurements, the Telemetry module also
In addition to system measurements, the Telemetry service also
captures event notifications triggered when various actions are
executed in the OpenStack system. This data is captured as Events and
stored alongside metering data.
@ -26,7 +26,7 @@ stored alongside metering data.
The list of meters is continuously growing, which makes it possible
to use the data collected by Telemetry for different purposes, other
than billing. For example, the autoscaling feature in the
Orchestration module can be triggered by alarms this module sets and
Orchestration service can be triggered by alarms this module sets and
then gets notified within Telemetry.
The sections in this document contain information about the

2
doc/user-guide-admin/source/dashboard_view_cloud_resources.rst
View File

@ -2,7 +2,7 @@
View cloud usage statistics
===========================
The Telemetry module provides user-level usage data for
The Telemetry service provides user-level usage data for
OpenStack-based clouds, which can be used for customer billing, system
monitoring, or alerts. Data can be collected by notifications sent by
existing OpenStack components (for example, usage events emitted from

2
doc/user-guide/source/backup_db.rst
View File

@ -3,7 +3,7 @@ Backup and restore a database
=============================
You can use Database services to backup a database and store the backup
artifact in the Object Storage module. Later on, if the original
artifact in the Object Storage service. Later on, if the original
database is damaged, you can use the backup artifact to restore the
database. The restore process creates a database instance.

4
doc/user-guide/source/cli_create_and_manage_stacks.rst
View File

@ -2,8 +2,8 @@
Create and manage stacks
========================
The Orchestration module enables you to orchestrate multiple composite
cloud applications. This module supports use of both the Amazon Web
The Orchestration service enables you to orchestrate multiple composite
cloud applications. This service supports use of both the Amazon Web
Services (AWS) CloudFormation template format through both a Query API
that is compatible with CloudFormation and the native OpenStack
:term:`Heat Orchestration Template (HOT)` format through a REST API.

2
doc/user-guide/source/dashboard_databases.rst
View File

@ -103,7 +103,7 @@ Backup and restore a database
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can use Database services to backup a database and store the backup
artifact in the Object Storage module. Later on, if the original
artifact in the Object Storage service. Later on, if the original
database is damaged, you can use the backup artifact to restore the
database. The restore process creates a database instance.