Feature Overview 

Ability to request data from the data storage domains for the purposes of generating cloud resource usage reports and billing, allowing for consumption by external FinOps or billing systems.

We are initiating a project to build chargeback capability for our OpenStack environment. Customers need the ability to understand their cloud usage for the purposes of:

• Transparent Cost Recovery
• Customer Trust and Competitive Differentiation

Chargeback provides visibility about cloud resource consumption with various customer domains. 

Why does the customer need this? (List the business requirements)

Transparent Cost Recovery

• As a cloud provider, the organization operates at large scale, offering on-demand compute, storage, and network resources to multiple tenants. Showback provides a clear, itemized breakdown of resource usage per tenant, ensuring each customer understands what they are consuming and the associated costs.
• By attributing real-time or monthly costs to usage (e.g., compute hours, storage GB-month, bandwidth), the cloud provider can recoup operational expenses without surprising customers with opaque billing.
• Showback also encourages optimized resource usage. When tenants see how their consumption affects costs, they can make informed decisions (e.g., rightsizing virtual machines or archiving stale data).

Customer Trust and Competitive Differentiation

• Offering transparent consumption reports increases customer trust. Tenants value clarity on how they are being charged or how their resource usage impacts their budget.
• In a competitive market, having robust chargeback capabilities can differentiate the cloud provider by demonstrating cost visibility.
• Chargeback enables additional use cases and an ability to become a cloud provider.

Goals

• This feature should allow for billing of tenants and resource planning based on tenant usage
• Usage should be available as a RAW data output from the CLI
• Usage should be based on the requirements agreed upon below in the requirements

Requirements 

To achieve a comprehensive view of IaaS consumption, we require the collection of specific metrics from the following services:

• Nova (Compute)
• Cinder (Block Storage)
• Manila (Shared File Systems)
• Neutron (Networking)
• Keystone (Identity)
• Ironic (Bare Metal)
• Octavia (Load Balancing, including OVN load balancers)
• Swift (Object Storage)
• Glance (Image Service)
• Barbican (Key Management)
• Designate (DNS)
• Heat (Orchestration)

Use Cases

• Collection of usage rates and data export based on flavor type
• As the administrator and customer of RHOSO, I want to reliably generate and access, itemized, raw data output (preferably JSON) of OpenStack resource usage for all my tenants, specifically ensuring that compute resources, <metric_1>, <metric_2, ..., and  <metric_n> are broken down by instance flavor and identified project names (resolved from project IDs for better understanding), so that I can implement transparent cost recovery for my tenants, integrate this data into my internal FinOps or billing solutions, and support my strategic capacity planning and operational efficiency initiatives.
• While report generation will utilize the UUID by default, it should be possible to perform a lookup to get the vanity name of the UUID values.

Out of Scope

• Providing a billing interface and report generation that could be used for billing directly from the implementation.
• Interfacing with Horizon or other GUI systems.

Documentation Considerations

• Product documentation
• Minimal amount of information allowing for data collection enablement and access to creating the queries (ratings) required for the data export.

• Product Management to create a blog post provides a walk through of a general use case with examples and output provided from the CLI.

Questions to Answer

• Can we get functionality merged and backported allowing the retrieval of flavor attributes from the compute systems.
• Is it possible to get Manila data?
• Can we get Loki team sign off and an internal support agreement for usage of Loki within OpenStack customer environments?
• Do we need swift/S3 sign off?
• Do we need nova? Sign off for flavor?

Risks

• upstream patch to provide storage adapter for Loki
• downstream Loki being able to deploy on CRC for purposes of being enabled in the testing framework
• deployment of a production-style compact OpenShift cluster with a production style Loki environment for review and sign off by the Loki team
• getting CloudKitty image builds early enough in the development timeline to allow for testing and validation prior to shipping FR4

Background and Strategic Fit

This Feature is of high importance for a lot of new customers. Their use case could, as an example, be to build cloud services on their machines and hence would billing be crucial.

Customer Considerations

This feature is built from customer needs and should be continuously evaluated with the customer.