replace 'metrics' with 'meters' wherever it makes sense

Replaced 'metrics' with 'meters' in all contexts, excluding the
metric system or  where the term is used as name.

Change-Id: If4c32dfe92c28a2079a485a6aec1d61c7b9999a1
Closes-Bug: #1446518

doc/admin-guide-cloud-rst/source/objectstorage-monitoring.rst

@@ -166,22 +166,22 @@ in ``self.logger``, has these new methods:
    Controller object is determined and instantiated for the request.
 
 -  ``update_stats(self, metric, amount, sample_rate=1)`` Increments the supplied
-   metric by the given amount. This is used when you need to add or
+   meter by the given amount. This is used when you need to add or
    subtract more that one from a counter, like incrementing
    "suffix.hashes" by the number of computed hashes in the object
    replicator.
 
 -  ``increment(self, metric, sample_rate=1)`` Increments the given counter
-   metric by one.
+   meter by one.
 
 -  ``decrement(self, metric, sample_rate=1)`` Lowers the given counter
-   metric by one.
+   meter by one.
 
--  ``timing(self, metric, timing_ms, sample_rate=1)`` Record that the given metric
+-  ``timing(self, metric, timing_ms, sample_rate=1)`` Record that the given meter
    took the supplied number of milliseconds.
 
 -  ``timing_since(self, metric, orig_time, sample_rate=1)`` Convenience method to record
-   a timing metric whose value is "now" minus an existing timestamp.
+   a timing meter whose value is "now" minus an existing timestamp.
 
 Note that these logging methods may safely be called anywhere you have a
 logger object. If StatsD logging has not been configured, the methods

doc/admin-guide-cloud/section_object-storage-monitoring.xml

@@ -212,7 +212,7 @@ log_statsd_default_sample_rate = 1</literallayout>
             <listitem>
                 <para><code>update_stats(self, metric, amount,
                         sample_rate=1)</code> Increments the supplied
-                    metric by the given amount. This is used when you
+                    meter by the given amount. This is used when you
                     need to add or subtract more that one from a
                     counter, like incrementing "suffix.hashes" by the
                     number of computed hashes in the object
@@ -221,23 +221,23 @@ log_statsd_default_sample_rate = 1</literallayout>
             <listitem>
                 <para><code>increment(self, metric,
                         sample_rate=1)</code> Increments the given
-                    counter metric by one.</para>
+                    counter meter by one.</para>
             </listitem>
             <listitem>
                 <para><code>decrement(self, metric,
                         sample_rate=1)</code> Lowers the given counter
-                    metric by one.</para>
+                    meter by one.</para>
             </listitem>
             <listitem>
                 <para><code>timing(self, metric, timing_ms,
                         sample_rate=1)</code> Record that the given
-                    metric took the supplied number of
+                    meter took the supplied number of
                     milliseconds.</para>
             </listitem>
             <listitem>
                 <para><code>timing_since(self, metric, orig_time,
                         sample_rate=1)</code> Convenience method to
-                    record a timing metric whose value is "now" minus
+                    record a timing meter whose value is "now" minus
                     an existing timestamp.</para>
             </listitem>
         </itemizedlist>

doc/arch-design/compute_focus/section_architecture_compute_focus.xml

@@ -201,7 +201,7 @@
         <para>Expandability refers to the overall ability of
           a storage solution to grow. A solution that expands to 50 PB is
           more expandable than a solution that only scales to 10PB.
-          Note that this metric is related to, but different
+          Note that this meter is related to, but different
           from, scalability, which is a measure of the solution's
           performance as it expands.</para>
       </listitem>

doc/arch-design/compute_focus/section_operational_considerations_compute_focus.xml

@@ -71,7 +71,7 @@
     <para>OpenStack clouds require appropriate monitoring platforms that
       help to catch and manage errors adequately. Consider leveraging any
       existing monitoring systems to see if they are able to
-      effectively monitor an OpenStack environment. Specific metrics that
+      effectively monitor an OpenStack environment. Specific meters that
       are critically important to capture include:</para>
       <itemizedlist>
         <listitem>

doc/arch-design/generalpurpose/section_architecture_general_purpose.xml

@@ -174,7 +174,7 @@
             <para>Sizing is an important
                 consideration for a general purpose OpenStack cloud.
                 The expected or anticipated number of instances that
-                each hypervisor can host is a common metric used in
+                each hypervisor can host is a common meter used in
                 sizing the deployment. The selected server hardware
                 needs to support the expected or anticipated instance
                 density.</para>
@@ -288,7 +288,7 @@
                 storage solutions with general purpose OpenStack
                 cloud. A storage solution that expands
                 to 50&nbsp;PB is considered more expandable than a
-                solution that only scales to 10&nbsp;PB. This metric is
+                solution that only scales to 10&nbsp;PB. This meter is
                 related to, but different, from scalability, which is a
                 measure of the solution's performance as it expands. For example, the storage
                 architecture for a cloud that is intended for a development

doc/arch-design/generalpurpose/section_operational_considerations_general_purpose.xml

@@ -56,7 +56,7 @@
       <title>Monitoring</title>
     <para>OpenStack clouds require appropriate monitoring platforms to
         ensure errors are caught and managed appropriately. Specific
-        metrics that are critically important to monitor include:</para>
+        meters that are critically important to monitor include:</para>
       <itemizedlist>
         <listitem>
           <para>

doc/arch-design/hybrid/section_tech_considerations_hybrid.xml

@@ -73,7 +73,7 @@
         experiences an unexpected increase in popularity. It is possible
         to define application requirements in terms of vCPU, RAM, bandwidth
         or other resources and plan appropriately. However, other clouds
-        might not use the same metric or even the same oversubscription rates.</para>
+        might not use the same meter or even the same oversubscription rates.</para>
     <para>Oversubscription is a method to emulate more capacity than
         may physically be present. For example, a physical
         hypervisor node with 32&nbsp;GB RAM may host 24

doc/arch-design/introduction/section_methodology.xml

@@ -60,7 +60,7 @@
             <para>Use the appropriate tools for the development effort.</para>
         </listitem>
         <listitem>
-            <para>Create better and more test metrics and test harnesses to
+            <para>Create better and more test meters and test harnesses to
                 support continuous and integrated development, test processes
                 and automation.</para>
         </listitem>
@@ -80,7 +80,7 @@
         cloud for the company's E-commerce website. This goal means planning for
         applications that will support thousands of sessions per second,
         variable workloads, and lots of complex and changing data. By
-        identifying the key metrics, such as number of concurrent transactions
+        identifying the key meters, such as number of concurrent transactions
         per second, size of database, and so on, it is possible to then build a
         method for testing the assumptions.</para>
     <formalpara>
@@ -91,7 +91,7 @@
         trajectory. If the organization is not ready to commit to an
         application or applications that can be used to develop user
         requirements, it needs to create requirements to build valid
-        test harnesses and develop usable metrics. Once the metrics
+        test harnesses and develop usable meters. Once the meters
         are established, as requirements change, it is easier to
         respond to the changes quickly without having to worry overly
         much about setting the exact requirements in advance. Think of

doc/arch-design/massively_scalable/section_operational_considerations_massively_scalable.xml

@@ -78,8 +78,8 @@
     <para>An important consideration in running at massive scale is
         projecting growth and utilization trends in order to plan capital
         expenditures for the short and long term. Gather utilization
-        metrics for compute, network, and storage, along with historical
+        meters for compute, network, and storage, along with historical
-        records of these metrics. While securing major
+        records of these meters. While securing major
         anchor tenants can lead to rapid jumps in the utilization
         rates of all resources, the steady adoption of the cloud
         inside an organization or by consumers in a public

doc/arch-design/storage_focus/section_architecture_storage_focus.xml

@@ -64,7 +64,7 @@
                 to grow. A storage solution that expands to 50 PB is
                 more expandable than a solution that only scales to 10 PB.</para>
               <note>
-                <para>This metric is related to scalability.
+                <para>This meter is related to scalability.
                 </para>
               </note>
         </listitem>

doc/common/samples/ceilometer.conf

@@ -310,7 +310,7 @@
 #rest_notifier_max_retries = 0
 
 # Period of evaluation cycle, should be >= than configured pipeline
-# interval for collection of underlying metrics. (integer value)
+# interval for collection of underlying meters. (integer value)
 # Deprecated group/name - [alarm]/threshold_evaluation_interval
 #evaluation_interval = 60
 

doc/config-reference/block-storage/drivers/vmware-vmdk-driver.xml

@@ -409,7 +409,7 @@
             lowest space utilization, where space utilization is
             defined by the
                 <literal>(1-freespace/totalspace)</literal>
-            metric.</para>
+            meters.</para>
         <para>These actions reduce the number of volume migrations
             while attaching the volume to instances.</para>
         <para>The volume must be migrated if the ESX host for the

doc/config-reference/compute/section_compute-scheduler.xml

@@ -659,9 +659,9 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-
         </section>
         <section xml:id="metricsfilter">
           <title>MetricsFilter</title>
-          <para>Filters hosts based on metrics
+          <para>Filters hosts based on meters
           <literal>weight_setting</literal>. Only hosts with the
-          available metrics are passed so that the metrics weigher
+          available meters are passed so that the metrics weigher
           will not fail due to these hosts.
           </para>
         </section>
@@ -886,13 +886,13 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-
                 <tr valign="top">
                     <td>[metrics]</td>
                     <td><literal>weight_multiplier</literal></td>
-                    <td>Multiplier for weighting metrics. Use a
+                    <td>Multiplier for weighting meters. Use a
                         floating-point value.</td>
                 </tr>
                 <tr valign="top">
                     <td>[metrics]</td>
                     <td><literal>weight_setting</literal></td>
-                    <td>Determines how metrics are weighted. Use a
+                    <td>Determines how meters are weighted. Use a
                         comma-separated list of metricName=ratio. For
                         example: "name1=1.0, name2=-1.0" results in:
                             <literal>name1.value * 1.0 + name2.value *
@@ -902,7 +902,7 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-
                 <tr valign="top">
                     <td>[metrics]</td>
                     <td><literal>required</literal></td>
-                    <td><para>Specifies how to treat unavailable metrics:<itemizedlist>
+                    <td><para>Specifies how to treat unavailable meters:<itemizedlist>
                                 <listitem>
                                    <para>True&mdash;Raises an
                                    exception. To avoid the raised
@@ -910,7 +910,7 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-
                                    scheduler filter
                                    <literal>MetricFilter</literal> to
                                    filter out hosts with unavailable
-                                   metrics.</para>
+                                   meters.</para>
                                 </listitem>
                                 <listitem>
                                    <para>False&mdash;Treated as a
@@ -925,7 +925,7 @@ isolated_images = 342b492c-128f-4a42-8d3a-c5088cf27d13, ebd267a6-ca86-4d6c-9a0e-
                     <td>[metrics]</td>
                     <td><literal>weight_of_unavailable</literal></td>
                     <td>If <option>required</option> is set to False,
-                        and any one of the metrics set by
+                        and any one of the meters set by
                             <option>weight_setting</option> is
                         unavailable, the
                             <option>weight_of_unavailable</option>

doc/glossary/glossary-terms.xml

@@ -444,7 +444,7 @@
       <glossdef>
         <para>The daemon, worker, or service that a client communicates with
         to access an API. API endpoints can provide any number of services,
-        such as authentication, sales data, performance metrics, Compute VM
+        such as authentication, sales data, performance meters, Compute VM
         commands, census data, and so on.</para>
       </glossdef>
     </glossentry>
@@ -7118,7 +7118,7 @@
         </indexterm>
 
       <glossdef>
-        <para>An Object Storage component that collects metrics.</para>
+        <para>An Object Storage component that collects meters.</para>
       </glossdef>
     </glossentry>
 
@@ -8365,7 +8365,7 @@
 
       <glossdef>
         <para>A Compute component that, along with the notification system,
-        collects metrics and usage information. This information can be used
+        collects meters and usage information. This information can be used
         for billing.</para>
       </glossdef>
     </glossentry>

doc/install-guide/section_ceilometer-cinder.xml

@@ -35,7 +35,7 @@ notification_driver = messagingv2</programlisting>
     </step>
     <step>
       <para>Use the <command>cinder-volume-usage-audit</command> command to
-        retrieve metrics on demand. For more information, see
+        retrieve meters on demand. For more information, see
         <link xlink:href="http://docs.openstack.org/admin-guide-cloud/content/section_telemetry-cinder-audit-script.html"
         ><citetitle>Block Storage audit script setup to get notifications</citetitle></link>.</para>
     </step>

doc/install-guide/section_ceilometer-nova.xml

@@ -7,7 +7,7 @@
   <?dbhtml stop-chunking?>
   <title>Configure the Compute service</title>
   <para>Telemetry uses a combination of notifications and an agent to
-    collect Compute metrics. Perform these steps on each compute node.</para>
+    collect Compute meters. Perform these steps on each compute node.</para>
   <procedure>
     <title>To install and configure the agent</title>
     <step>

doc/install-guide/section_swift-storage-node.xml

@@ -228,7 +228,7 @@ pipeline = healthcheck recon account-server</programlisting>
         </step>
         <step>
           <para>In the <literal>[filter:recon]</literal> section, configure
-            the recon (metrics) cache directory:</para>
+            the recon (meters) cache directory:</para>
           <programlisting language="ini">[filter:recon]
 ...
 recon_cache_path = /var/cache/swift</programlisting>
@@ -270,7 +270,7 @@ pipeline = healthcheck recon container-server</programlisting>
         </step>
         <step>
           <para>In the <literal>[filter:recon]</literal> section, configure
-            the recon (metrics) cache directory:</para>
+            the recon (meters) cache directory:</para>
           <programlisting language="ini">[filter:recon]
 ...
 recon_cache_path = /var/cache/swift</programlisting>
@@ -312,7 +312,7 @@ pipeline = healthcheck recon object-server</programlisting>
         </step>
         <step>
           <para>In the <literal>[filter:recon]</literal> section, configure
-            the recon (metrics) cache and lock directories:</para>
+            the recon (meters) cache and lock directories:</para>
           <programlisting language="ini">[filter:recon]
 ...
 recon_cache_path = /var/cache/swift

doc/user-guide-admin/source/dashboard_manage_instances.rst

@@ -57,7 +57,7 @@ Track usage
 
 Use the Overview category to track usage of instances for each project.
 
-You can track costs per month by showing metrics like number of VCPUs,
+You can track costs per month by showing meters like number of VCPUs,
 disks, RAM, and uptime of all your instances.
 
 #. Log in to the dashboard and choose the admin project from the CURRENT

doc/user-guide-admin/source/dashboard_view_cloud_resources.rst

@@ -39,5 +39,5 @@ View resource statistics
      networks, subnets, routers, ports, and floating IPs, per tenant (project).
 
    * :guilabel:`Stats` tab to view a multi-series line chart with user-defined
-     metrics. You group by project, define the value type (min, max, avg, or sum),
+     meters. You group by project, define the value type (min, max, avg, or sum),
      and specify the time period (or even use a calendar to define a date range).

doc/user-guide/source/dashboard_launch_instances.rst

@@ -185,7 +185,7 @@ Track usage for instances
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 You can track usage for instances for each project. You can track costs
-per month by showing metrics like number of vCPUs, disks, RAM, and
+per month by showing meters like number of vCPUs, disks, RAM, and
 uptime for all your instances.
 
 #. Log in to the dashboard, choose a project, and click :guilabel:`Overview`.