openstack
/
ceilometer
Code Issues Proposed changes

Replace 'metrics' with 'meters' in option and doc 

So that the openstack manuals are consistent and use the same (right)
term, this replaces the term 'metrics' with 'meters' in the help for
the config and develop docs.

DocImpact

Closes-bug: #1436371

Change-Id: Iadc81a936f75dbe619130b3434188f564b67efd5
This commit is contained in:
Edwin Zhai 2015-04-08 15:56:06 +08:00
parent c9a42be186
commit 773370901d
5 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
ceilometer/alarm/service.py
View File

@ -40,7 +40,7 @@ OPTS = [
default=60,
help='Period of evaluation cycle, should'
' be >= than configured pipeline interval for'
' collection of underlying metrics.',
' collection of underlying meters.',
deprecated_opts=[cfg.DeprecatedOpt(
'threshold_evaluation_interval', group='alarm')]),
]

2
doc/source/measurements.rst
View File

@ -22,7 +22,7 @@
Existing meters
===============
For the list of existing metrics see the tables under the
For the list of existing meters see the tables under the
`Measurements page`_ of Ceilometer in the Cloud Administrator Guide.
.. _Measurements page: http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-measurements.html

6
doc/source/overview.rst
View File

@ -12,14 +12,14 @@ single source to transform events into billable items which we
label as "metering".
As the project started to come to life, collecting an
`increasing number of metrics`_ across multiple projects, the OpenStack
`increasing number of meters`_ across multiple projects, the OpenStack
community started to realize that a secondary goal could be added to
Ceilometer: become a standard way to collect metric, regardless of the
Ceilometer: become a standard way to collect meter, regardless of the
purpose of the collection. For example, Ceilometer can now publish information
for monitoring, debugging and graphing tools in addition or in parallel to the
metering backend. We labelled this effort as "multi-publisher".
.. _increasing number of metrics: http://docs.openstack.org/developer/ceilometer/measurements.html
.. _increasing number of meters: http://docs.openstack.org/developer/ceilometer/measurements.html
Most recently, as the Heat project started to come to
life, it soon became clear that the OpenStack project needed a tool to watch

6
doc/source/plugins.rst
View File

@ -30,8 +30,8 @@ Polling agent might be run either on central cloud management nodes or on the
compute nodes (where direct hypervisor polling is quite logical).
The agent running on each compute node polls for compute resources
usage. Each metric collected is tagged with the resource ID (such as
an instance) and the owner, including tenant and user IDs. The metrics
usage. Each meter collected is tagged with the resource ID (such as
an instance) and the owner, including tenant and user IDs. The meters
are then reported to the collector via the message bus. More detailed
information follows.
@ -136,7 +136,7 @@ generates the appropriate sample objects to be sent to the collector.
Adding new plugins
------------------
Although we have described a list of the metrics Ceilometer should
Although we have described a list of the meters Ceilometer should
collect, we cannot predict all of the ways deployers will want to
measure the resources their customers use. This means that Ceilometer
needs to be easy to extend and configure so it can be tuned for each

2
doc/source/webapi/v2.rst
View File

@ -313,7 +313,7 @@ Functional examples
+++++++++++++++++++
The examples below are meant to help you understand how to query the
Ceilometer API to build custom metrics report. The query parameters should
Ceilometer API to build custom meters report. The query parameters should
be encoded using one of the above methods, e.g. as the URL parameters or
as JSON encoded data passed to the GET request.