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 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 #. An admin-only RESTful API service, by which privileged users, such
as cloud operators and other services within the cloud control 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 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 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 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 Orchestration stacks are defined with templates, which are non-procedural
documents that describe tasks in terms of resources, parameters, inputs, 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 Alarms provide user-oriented Monitoring-as-a-Service for resources
running on OpenStack. This type of monitoring ensures you can running on OpenStack. This type of monitoring ensures you can
automatically scale in or out a group of instances through the 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. awareness of your cloud resources' health.
These alarms follow a tri-state model: These alarms follow a tri-state model:
@ -46,7 +46,7 @@ governed by:
Combination rule alarms 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 aggregates over the current state of a set of underlying basic alarms
combined via a logical operator (AND or OR). 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 where this selection identifies many resources over which the
statistic is aggregated. For example all instances booted from a statistic is aggregated. For example all instances booted from a
particular image or all instances with matching user metadata (the 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). groups).
Alarm evaluation 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 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. all the data will be relevant for a cloud administrator to monitor.
- Based on your needs, you can edit the :file:`pipeline.yaml` configuration - 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 can be metered, like the CPU time of a VM instance created by OpenStack
Compute service. 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 consuming notifications, namely the notification agent. This component
is responsible for consuming from the message bus and transforming is responsible for consuming from the message bus and transforming
notifications into events and measurement samples. Beginning in the Liberty 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 The different OpenStack services emit several notifications about the
various types of events that happen in the system during normal various types of events that happen in the system during normal
operation. Not all these notifications are consumed by the Telemetry 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 notifications that can be used for monitoring or profiling purposes. The
notification agent filters by the event type, that is contained by each notification agent filters by the event type, that is contained by each
notification message. The following table contains the event types by 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 | | | | l3.meter | |
+--------------------+------------------------+-------------------------------+ +--------------------+------------------------+-------------------------------+
| Orchestration | orchestration.stack\ | | | Orchestration | orchestration.stack\ | |
| module | .create.end | | | service | .create.end | |
| | | | | | | |
| | orchestration.stack\ | | | | orchestration.stack\ | |
| | .update.end | | | | .update.end | |
@ -201,7 +201,7 @@ notifications.
Polling 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 infrastructure. This goal requires additional information than what is
provided by the events and notifications published by each service. Some provided by the events and notifications published by each service. Some
information is not emitted directly, like resource usage of the VM 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>`__ - Energy consumption meters via `Kwapi <https://launchpad.net/kwapi>`__
framework 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>`__ <http://docs.openstack.org/liberty/install-guide-ubuntu/ceilometer.html>`__
section in the OpenStack Installation Guide. 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 list of collected meters can be found in :ref:`telemetry-compute-meters`.
The support column provides the information that which meter is available for 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:: .. note::
@ -451,9 +451,9 @@ in the :file:`ceilometer.conf` configuration file.
Send samples to Telemetry 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 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 This option makes it possible to send any kind of samples without the
need of writing extra code lines or making configuration changes. need of writing extra code lines or making configuration changes.
@ -862,12 +862,12 @@ Example configuration::
Meter definitions Meter definitions
----------------- -----------------
The Telemetry module collects a subset of the meters by filtering notifications The Telemetry service collects a subset of the meters by filtering
emitted by other OpenStack services. Starting with the Liberty release, you can notifications emitted by other OpenStack services. Starting with the Liberty
find the meter definitions in a separate configuration file, called release, you can find the meter definitions in a separate configuration file,
:file:`ceilometer/meter/data/meter.yaml`. This enables operators/administrators called :file:`ceilometer/meter/data/meter.yaml`. This enables
to add new meters to Telemetry project by updating the :file:`meter.yaml` operators/administrators to add new meters to Telemetry project by updating
file without any need for additional code changes. the :file:`meter.yaml` file without any need for additional code changes.
.. note:: .. note::
@ -972,7 +972,7 @@ the following format::
This script outputs what volumes or snapshots were created, deleted, or This script outputs what volumes or snapshots were created, deleted, or
exists in a given period of time and some information about these exists in a given period of time and some information about these
volumes or snapshots. Information about the existence and size of 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 also stored as an event which is the recommended usage as it provides
better indexing of data. better indexing of data.
@ -985,7 +985,7 @@ example, every 5 minutes::
Storing samples 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 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, 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 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 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 target. The samples are sent without any modification. To set this
option as the collector's target, the ``dispatcher`` has to be changed option as the collector's target, the ``dispatcher`` has to be changed
to ``http`` in the :file:`ceilometer.conf` configuration file. For the list to ``http`` in the :file:`ceilometer.conf` configuration file. For the list
@ -1069,7 +1069,7 @@ in the OpenStack Configuration Reference.
Gnocchi dispatcher 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 through the gnocchi dispatcher. To set this option as the target, change the
``dispatcher`` to ``gnocchi`` in the :file:`ceilometer.conf` ``dispatcher`` to ``gnocchi`` in the :file:`ceilometer.conf`
configuration file. configuration file.

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

@ -2,7 +2,7 @@
Data retrieval 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 data can be accessed. As described in :ref:`telemetry-system-architecture` and
in :ref:`telemetry-data-collection`, the collected information can be stored in 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. 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 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 samples and all the related information can be retrieved, like the list
of meters, alarm definitions and so forth. of meters, alarm definitions and so forth.
@ -177,7 +177,7 @@ in a single API request.
Telemetry command line client and SDK 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 collected data is available just as the alarm definition and retrieval
options. The client uses the Telemetry RESTful API in order to execute options. The client uses the Telemetry RESTful API in order to execute
the requested operations. the requested operations.
@ -190,7 +190,7 @@ in the OpenStack Installation Guide.
.. note:: .. 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 Therefore the database will not contain any data without the
existence of these resources, like VM images in the OpenStack Image existence of these resources, like VM images in the OpenStack Image
service. service.
@ -465,7 +465,7 @@ reference.
Publishers 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 data collected to the ceilometer-collector service or to an external
system. The consumers of this data are widely different, like monitoring system. The consumers of this data are widely different, like monitoring
systems, for which data loss is acceptable and billing systems, which 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. consumers. One chain can contain multiple publishers.
To solve the above mentioned problem, the notion of multi-publisher can 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 the same technical meter or event to be published multiple times to
multiple destinations, each potentially using a different transport. multiple destinations, each potentially using a different transport.

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

@ -2,9 +2,9 @@
Events 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 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 While a sample represents a single, numeric datapoint within a
time-series, an event is a broader concept that represents the state of 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 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 ``store_events`` option needs to be set to ``True``. For further configuration
options, see the event section in the `OpenStack Configuration Reference options, see the event section in the `OpenStack Configuration Reference
<http://docs.openstack.org/kilo/config-reference/content/ch_configuring-openstack-telemetry.html>`__. <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:: .. note::
It is advisable to set ``disable_non_metric_meters`` to ``True`` 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 historically represented events as metering data, which may create
duplication of data if both events and non-metric meters are duplication of data if both events and non-metric meters are
enabled. enabled.
Event structure 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: attributes:
event\_type event\_type
@ -83,7 +83,7 @@ fields in the notification exist and are non-null.
.. note:: .. 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 contains a list of known notifications and useful traits. The
mappings provided can be modified to include more or less data mappings provided can be modified to include more or less data
according to user requirements. according to user requirements.

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

@ -4,7 +4,7 @@
Measurements 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 This section provides a brief summary about meters format and origin and
also contains the list of available meters. 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. external and internal users.
Measurements are grouped by services which are polled by 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:: .. 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 functionality was added later, therefore the list of meters still
contains existence type and other event related items. The proper contains existence type and other event related items. The proper
way of using Telemetry is to configure it to use the event store and 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> 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 transformers. For more details about transformers see
:ref:`telemetry-transformers`. Among the meters gathered from libvirt and :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 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 | | | | | | | l.rule.update | | | | | |
+---------------+-------+---------+------------+-----------+------------------+ +---------------+-------+---------+------------+-----------+------------------+
Orchestration module Orchestration service
~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
The following meters are collected for the Orchestration module: The following meters are collected for the Orchestration service:
+----------------+-------+------+----------+--------------+-------------------+ +----------------+-------+------+----------+--------------+-------------------+
| Name | Type | Unit | Resource | Origin | Note | | Name | Type | Unit | Resource | Origin | Note |

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

@ -4,11 +4,11 @@
System architecture 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 combine their responsibilities to collect data, store samples in a
database, or provide an API service for handling incoming requests. 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 ceilometer-api
Presents aggregated metering data to consumers (such as billing Presents aggregated metering data to consumers (such as billing
@ -106,7 +106,7 @@ The list of supported database back ends:
Supported hypervisors 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 which requires close connection to the hypervisor that runs on the
compute hosts. compute hosts.
@ -168,7 +168,7 @@ external networking services:
Users, roles and tenants 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 authorizing users. The required configuration options are listed in the
`Telemetry `Telemetry
section <http://docs.openstack.org/kilo/config-reference/content/ch_configuring-openstack-telemetry.html>`__ 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 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 services. Multiple options are available to change the target of
logging, the format of the log entries and the log levels. 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 satisfies all. Providing users with measurements on cloud services is
required to meet the "measured service" definition of cloud computing. 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 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 collects information about the system and stores it in the form of
samples in order to provide data about anything that can be billed. 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 captures event notifications triggered when various actions are
executed in the OpenStack system. This data is captured as Events and executed in the OpenStack system. This data is captured as Events and
stored alongside metering data. stored alongside metering data.
@ -26,7 +26,7 @@ stored alongside metering data.
The list of meters is continuously growing, which makes it possible The list of meters is continuously growing, which makes it possible
to use the data collected by Telemetry for different purposes, other to use the data collected by Telemetry for different purposes, other
than billing. For example, the autoscaling feature in the 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. then gets notified within Telemetry.
The sections in this document contain information about the 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 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 OpenStack-based clouds, which can be used for customer billing, system
monitoring, or alerts. Data can be collected by notifications sent by monitoring, or alerts. Data can be collected by notifications sent by
existing OpenStack components (for example, usage events emitted from 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 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 is damaged, you can use the backup artifact to restore the
database. The restore process creates a database instance. 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 Create and manage stacks
======================== ========================
The Orchestration module enables you to orchestrate multiple composite The Orchestration service enables you to orchestrate multiple composite
cloud applications. This module supports use of both the Amazon Web cloud applications. This service supports use of both the Amazon Web
Services (AWS) CloudFormation template format through both a Query API Services (AWS) CloudFormation template format through both a Query API
that is compatible with CloudFormation and the native OpenStack that is compatible with CloudFormation and the native OpenStack
:term:`Heat Orchestration Template (HOT)` format through a REST API. :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 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 is damaged, you can use the backup artifact to restore the
database. The restore process creates a database instance. database. The restore process creates a database instance.