diff --git a/doc/admin-guide-cloud/source/baremetal.rst b/doc/admin-guide-cloud/source/baremetal.rst index 524bd2c28d..78fccffb4a 100644 --- a/doc/admin-guide-cloud/source/baremetal.rst +++ b/doc/admin-guide-cloud/source/baremetal.rst @@ -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 diff --git a/doc/admin-guide-cloud/source/orchestration-introduction.rst b/doc/admin-guide-cloud/source/orchestration-introduction.rst index 9c518fc78f..3d648af266 100644 --- a/doc/admin-guide-cloud/source/orchestration-introduction.rst +++ b/doc/admin-guide-cloud/source/orchestration-introduction.rst @@ -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, diff --git a/doc/admin-guide-cloud/source/telemetry-alarms.rst b/doc/admin-guide-cloud/source/telemetry-alarms.rst index e22e719183..ffa4a9f654 100644 --- a/doc/admin-guide-cloud/source/telemetry-alarms.rst +++ b/doc/admin-guide-cloud/source/telemetry-alarms.rst @@ -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 diff --git a/doc/admin-guide-cloud/source/telemetry-best-practices.rst b/doc/admin-guide-cloud/source/telemetry-best-practices.rst index dc01b61470..88ce961ac5 100644 --- a/doc/admin-guide-cloud/source/telemetry-best-practices.rst +++ b/doc/admin-guide-cloud/source/telemetry-best-practices.rst @@ -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 diff --git a/doc/admin-guide-cloud/source/telemetry-data-collection.rst b/doc/admin-guide-cloud/source/telemetry-data-collection.rst index 52c09b438c..34fac12010 100644 --- a/doc/admin-guide-cloud/source/telemetry-data-collection.rst +++ b/doc/admin-guide-cloud/source/telemetry-data-collection.rst @@ -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 `__ 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 `__ 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. diff --git a/doc/admin-guide-cloud/source/telemetry-data-retrieval.rst b/doc/admin-guide-cloud/source/telemetry-data-retrieval.rst index 009d7509ff..f9250880c8 100644 --- a/doc/admin-guide-cloud/source/telemetry-data-retrieval.rst +++ b/doc/admin-guide-cloud/source/telemetry-data-retrieval.rst @@ -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. diff --git a/doc/admin-guide-cloud/source/telemetry-events.rst b/doc/admin-guide-cloud/source/telemetry-events.rst index 8d25f32a7e..9b5a5ad2a2 100644 --- a/doc/admin-guide-cloud/source/telemetry-events.rst +++ b/doc/admin-guide-cloud/source/telemetry-events.rst @@ -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 `__. @@ -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. diff --git a/doc/admin-guide-cloud/source/telemetry-measurements.rst b/doc/admin-guide-cloud/source/telemetry-measurements.rst index 9d1a84289a..c7041a7bbb 100644 --- a/doc/admin-guide-cloud/source/telemetry-measurements.rst +++ b/doc/admin-guide-cloud/source/telemetry-measurements.rst @@ -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= -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 | diff --git a/doc/admin-guide-cloud/source/telemetry-system-architecture.rst b/doc/admin-guide-cloud/source/telemetry-system-architecture.rst index f3f104a4ed..f1675fa73c 100644 --- a/doc/admin-guide-cloud/source/telemetry-system-architecture.rst +++ b/doc/admin-guide-cloud/source/telemetry-system-architecture.rst @@ -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 `__ diff --git a/doc/admin-guide-cloud/source/telemetry-troubleshooting-guide.rst b/doc/admin-guide-cloud/source/telemetry-troubleshooting-guide.rst index 7d4a36e836..e8680e19c1 100644 --- a/doc/admin-guide-cloud/source/telemetry-troubleshooting-guide.rst +++ b/doc/admin-guide-cloud/source/telemetry-troubleshooting-guide.rst @@ -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. diff --git a/doc/admin-guide-cloud/source/telemetry.rst b/doc/admin-guide-cloud/source/telemetry.rst index 13be590e93..c37ffd5d26 100644 --- a/doc/admin-guide-cloud/source/telemetry.rst +++ b/doc/admin-guide-cloud/source/telemetry.rst @@ -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 diff --git a/doc/user-guide-admin/source/dashboard_view_cloud_resources.rst b/doc/user-guide-admin/source/dashboard_view_cloud_resources.rst index fbbaa0d9dd..bd8a766068 100644 --- a/doc/user-guide-admin/source/dashboard_view_cloud_resources.rst +++ b/doc/user-guide-admin/source/dashboard_view_cloud_resources.rst @@ -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 diff --git a/doc/user-guide/source/backup_db.rst b/doc/user-guide/source/backup_db.rst index 1ab96c2977..89becee471 100644 --- a/doc/user-guide/source/backup_db.rst +++ b/doc/user-guide/source/backup_db.rst @@ -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. diff --git a/doc/user-guide/source/cli_create_and_manage_stacks.rst b/doc/user-guide/source/cli_create_and_manage_stacks.rst index f7688b929a..814a1ba590 100644 --- a/doc/user-guide/source/cli_create_and_manage_stacks.rst +++ b/doc/user-guide/source/cli_create_and_manage_stacks.rst @@ -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. diff --git a/doc/user-guide/source/dashboard_databases.rst b/doc/user-guide/source/dashboard_databases.rst index e6f6af1fc8..e619ccbbd0 100644 --- a/doc/user-guide/source/dashboard_databases.rst +++ b/doc/user-guide/source/dashboard_databases.rst @@ -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.