docs(metering): fix trailing whitespaces

also fix a typo in the python-gnocchiclient url
add new line to end of metering-overview svg

docs/metering-billing.md

@@ -21,16 +21,16 @@ for usage-based billing of Genestack tenants.
    daily, or monthly usage_). Gnocchi provides quick access to the stored data,
    enabling near real-time billing operations.
 
-4. **Converting to Atom Events**: The billing system converts the collated 
+4. **Converting to Atom Events**: The billing system converts the collated
    resource usage data into Atom events before submitting them.
 
-5. **Submitting Events to Cloud Feeds**: Newly created Atom events are sent 
+5. **Submitting Events to Cloud Feeds**: Newly created Atom events are sent
    via HTTPS to Cloud Feeds.
 
-6. **Usage Mediation Services**: Our UMS team receives the metered usage 
-   events from the named feed, then does further aggregation before emitting 
+6. **Usage Mediation Services**: Our UMS team receives the metered usage
+   events from the named feed, then does further aggregation before emitting
    the usage to be invoiced.
 
-7. **Billing and Revenue Management**: Finally, the aggregated usage from 
-   UMS is received and processed by BRM to create the usage-based invoice 
+7. **Billing and Revenue Management**: Finally, the aggregated usage from
+   UMS is received and processed by BRM to create the usage-based invoice
    for each tenant.

docs/metering-ceilometer.md

@@ -3,9 +3,9 @@
 Ceilometer is the telemetry service in OpenStack responsible for collecting
 usage data related to different resources (_e.g., instances, volumes,
 and network usage_). It compiles various types of metrics (_referred to as
-meters_), such as CPU utilization, disk I/O, and network traffic. It does 
-this by gathering data from other OpenStack components like Nova (_compute_), 
-Cinder (_block storage_), and Neutron (_networking_). It also captures event 
+meters_), such as CPU utilization, disk I/O, and network traffic. It does
+this by gathering data from other OpenStack components like Nova (_compute_),
+Cinder (_block storage_), and Neutron (_networking_). It also captures event
 data such as instance creation and volume attachment via hooks into the message
 notification system (_RabbitMQ_).
 
@@ -27,7 +27,7 @@ their specific needs.
 
 Events are discrete occurrences, such as the starting or stopping of
 instances or attaching a volume which are captured and stored. Ceilometer
-builds event data from the messages it receives from other OpenStack 
+builds event data from the messages it receives from other OpenStack
 services. Event definitions can be complex. Typically, a given message will
 match one or more event definitions that describe what the incoming payload
 should be flattened to. See the [telemetry-events][ceilometer-events]
@@ -75,13 +75,13 @@ section of Ceilometer's documentation for more information.
 
 ### Resources
 
-Gnocchi resource definitions in Ceilometer's configuration define how resources 
-like instances, volumes, and networks are represented and tracked for 
-telemetry purposes. Each definition specifies the attributes (_such as project 
+Gnocchi resource definitions in Ceilometer's configuration define how resources
+like instances, volumes, and networks are represented and tracked for
+telemetry purposes. Each definition specifies the attributes (_such as project
 ID or instance name_) and the metrics (_like CPU usage or network traffic_)
 associated with that resource. When Ceilometer collects data from various
 OpenStack services, it uses these definitions to map the data to the appropriate
-resource type in Gnocchi (_which stores it as time-series data_). This 
+resource type in Gnocchi (_which stores it as time-series data_). This
 structure allows for efficient monitoring, aggregation, and analysis of resource
 usage over time in a scalable way.
 
@@ -123,8 +123,8 @@ usage over time in a scalable way.
 
 ### Meters
 
-Meters are quantitative measures like CPU time, memory usage, or disk 
-operations. Ceilometer provides several useful metrics by default, but new 
+Meters are quantitative measures like CPU time, memory usage, or disk
+operations. Ceilometer provides several useful metrics by default, but new
 definitions can be added to suit almost every need. To read more about
 measurements and how they are captured, see the [telemetry-measurements][ceilometer-telemetry]
 section of Ceilometer documentation.

docs/metering-chargebacks.md

@@ -6,12 +6,12 @@ costs of shared cloud resources to the responsible entity based on their usage.
 
 ## Theoretical Workflow
 
-1. **Customer Initiates Chargeback or Complaint**: The complaint is received 
-   by the responsible operational team that would handle such a dispute. Usage 
+1. **Customer Initiates Chargeback or Complaint**: The complaint is received
+   by the responsible operational team that would handle such a dispute. Usage
    can be re-calculated for a specific tenant over a given period of time.
 
-2. **Querying Usage Data**: The chargeback system queries Gnocchi for usage 
-   metrics that belong only to the specific projects of concern related to the 
+2. **Querying Usage Data**: The chargeback system queries Gnocchi for usage
+   metrics that belong only to the specific projects of concern related to the
    dispute. Gnocchi provides detailed, pre-aggregated data for each tracked
    resource, enabling the system to quickly access and analyze consumption.
 
@@ -21,7 +21,7 @@ costs of shared cloud resources to the responsible entity based on their usage.
    fixed rates for specific services (_e.g., $ per GB of storage or flavor_type
    $ per hour_), can be applied to determine the charges for each entity.
 
-4. **Reporting and Transparency**: The chargeback system could be made to 
-   generate reports detailing each project's resource consumption and 
-   associated costs. These reports provide transparency, allowing tenants to 
+4. **Reporting and Transparency**: The chargeback system could be made to
+   generate reports detailing each project's resource consumption and
+   associated costs. These reports provide transparency, allowing tenants to
    track their resource usage and associated expenses.

docs/metering-gnocchi.md

@@ -27,12 +27,12 @@ metric cleanup.
    <figcaption>Image source: <a href="https://gnocchi.osci.io/intro.html" target="_blank" rel="noopener noreferrer">gnocchi.osci.io</a></figcaption>
 </figure>
 
-Gnocchi services are stateless thus can be scaled horizontally without much 
+Gnocchi services are stateless thus can be scaled horizontally without much
 effort. That being said, we can easily define an HPA (HorizontalPodAutoscaler)
 policy to do just that for `ReplicaSet` components such as the `gnocchi-api`.
 However, `metricd` and `statsd` components are configured to be
-`DaemonSets`, so operators need only label additional nodes with the 
-configured node-selector key/value of `openstack-control-plane=enabled` to 
+`DaemonSets`, so operators need only label additional nodes with the
+configured node-selector key/value of `openstack-control-plane=enabled` to
 scale those components up or down.
 
 ## Storage
@@ -57,13 +57,13 @@ metrics, including:
 
 For smaller architectures, using the file driver to store data on disk may be
 sufficient. However, S3, Ceph, and Swift offer more scalable storage options,
-with Ceph being the recommended choice due to its better consistency. In 
+with Ceph being the recommended choice due to its better consistency. In
 larger or busier deployments, a common recommendation is to use Redis for
 incoming measure storage and Ceph for aggregate storage.
 
 ### Indexing
 
-The indexer driver stores the index of all resources, archive policies, and 
+The indexer driver stores the index of all resources, archive policies, and
 metrics, along with their definitions, types, and properties. It also handles
 the linking of resources to metrics and manages resource relationships.
 Supported drivers include the following:
@@ -81,9 +81,9 @@ creation if necessary.
 ## REST API Usage
 
 The Gnocchi REST API is well documented on their website, please see the
-[REST API Usage](https://gnocchi.osci.io/rest.html) section for full detail. 
-Furthermore, there is a community supported Python client and SDK 
-installable via pip, aptly named [python-gnocchiclient](https://github.
-com/gnocchixyz/pythongnocchiclient). It's worth noting, this is a required 
-module for `openstack metric` commands to function. See [OpenStack Metrics](openstack-metrics.md)
-for example CLI usage.
+[REST API Usage](https://gnocchi.osci.io/rest.html) section for full detail.
+Furthermore, there is a community supported Python client and SDK
+installable via pip, aptly named [python-gnocchiclient](https://github.com/gnocchixyz/python-gnocchiclient).
+It's worth noting, this is a required module for `openstack metric` commands
+to function. See [OpenStack Metrics](openstack-metrics.md) for example CLI
+usage.

docs/openstack-metrics.md

@@ -46,7 +46,7 @@ openstack metric create <metric_name> \
 - `--unit <unit>`: Specify the unit of measurement (e.g., MB, GB).
 - `--resource-id <resource_id>`: ID of the resource to associate the metric
   with.
-- `--archive-policy-name <policy_name>`: Name of the archive policy 
+- `--archive-policy-name <policy_name>`: Name of the archive policy
 
 ### **metric delete**
 
@@ -171,12 +171,12 @@ Creates a new resource-type
 
 ```shell
 openstack metric resource-type create <resource_type_name> \
-  --attribute <attributes> 
+  --attribute <attributes>
 ```
 
 **Options**:
 
-- `--attribute <display_name:string:true:max_length=255>`: attribute definition 
+- `--attribute <display_name:string:true:max_length=255>`: attribute definition
   > attribute_name:attribute_type:attribute_is_required:attribute_type_option_name=attribute_type_option_value
 
 ### **metric resource-type update**
@@ -191,9 +191,9 @@ openstack metric resource-type update <resource_type_name> \
 
 **Options**:
 
-- `--attribute <display_name:string:true:max_length=255>`: attribute definition 
+- `--attribute <display_name:string:true:max_length=255>`: attribute definition
   > attribute_name:attribute_type:attribute_is_required:attribute_type_option_name=attribute_type_option_value
-- `--remove-attribute <attribute_name>`: removes named 
+- `--remove-attribute <attribute_name>`: removes named
   attribute
 
 ### **metric archive-policy list**
@@ -272,7 +272,7 @@ openstack metric create cpu_usage --resource-id <resource_id> --unit GHz
 
 ### **Update the `image` Resource Type**
 
-In this example, we add a few additional useful image properties to the 
+In this example, we add a few additional useful image properties to the
 image resource type that we want to store.
 
 ```shell
@@ -283,10 +283,10 @@ openstack resource-type update image -a os_version:string:false:max_length=255
 
 !!! tip "Update related Ceilometer resource type attributes"
 
-    Note that changes to resource types to accomodate additional parameters 
+    Note that changes to resource types to accomodate additional parameters
     don't just magically work. One must update Ceilometer's resource_type
-    definitions. For the `image` resource_type, we do that in the ceilometer 
-    helm chart overrides here (for example), appending the keys and populate 
+    definitions. For the `image` resource_type, we do that in the ceilometer
+    helm chart overrides here (for example), appending the keys and populate
     the values using the related resource_metadata payload:
 
     ```yaml