The roll-out of additional services (PaaS, for example) has highlighted the need for a metering architecture that enables advanced billing models not currently handled in the Ceilometer collectors. Specific use cases include direct Nova billing, Windows instance and PaaS service controller-owned Nova instances (i.e. controller vs. user tenant id), PaaS application billing, and variations on quantity and overage billing. Adding support for these models will likely impact collection, data storage, and access control methodologies.
Key Use Cases
|Use Case||Sub Use Case||Details|
|Direct Billing of Nova instances(base use case)||The standard usage of the Nova compute and related services; each Nova instance is owned by a single end customer tenant. The images run in Nova do not contain any special licensing terms and thus do not add any additional premium to the charges for usage. Usage reporting captures the resources used by that instance (CPU, IO, networking, volume storage) and attributes it to the customer tenant. The tenant is directly charged for the usage.|
|Licensed Nova instances||A Nova instance that is running a licensed image (OS or application) for which the tenant may be charged a premium price above the base instance usage charges. Instances are owned and managed by the tenant account, so usage records are attributed directly to the tenant account. This use case requires a mechanism for identifying licensed images so that they can be processed and charged appropriately.
An example of this use case is where the image is running Windows. A premium charge (e.g., a licensing fee) may be associated with these images, so the system must provide appropriate metadata about the image and instance so that the appropriate charges can be applied.
|Premium Priced Billing for service instance usage owned by a PaaS service controller||This is a variation of the licensed Nova instance use case (i.e. premium pricing for specially licensed OS or application functionality) but with a different VM instance ownership/management model. A Nova or other service instance that is instantiated and managed by the PaaS service controller which runs under its own account. Specifically, the assigned tenantID of an instances is associated with service controller rather than actual user. The user does not directly control the instance but accesses a abstracted service running on top and it is this service that they are buying. Reporting of usage occurs in the same manner as the base Nova use case, but the tenantID in the usage records is that of the service controller. Mechanisms are required to:
|Hosted application billing||Users are charged for an application running on a set of Nova instances that are hosting an application, while the host Nova instance may itself not be metered. Nova instances running these kinds of applications must be identifiable so that the appropriate processing will take place. In many cases that will mean that the underlying VM usage is not charged for, but a set of application usage records are tracked instead. There are three variations of this model (listed below)|
|Ongoing subscriptions|| Users subscribe to a service and are charged based on the duration of the subscription. Usage reporting must track the creation, ongoing existence and status, removal of the subscription and generate appropriate billing records. Users are not charged for the underlying VM instance or the specific activity generated to support the subscription.
An example of this kind of billing model would be a monitoring service. Users subscribe to monitor one or more instances. While they are subscribed the system must generate a set of usage records that track the state of the subscription.
|Quantity usage based on number of meters|| Users consume a service that runs on VM instances. They are charged for the actual number of meters generated instead of the underlying usage of the VM. Usage records for this kind of service would contain a custom meter and associated quantity.
An example of this kind of billing model would be a messaging service. Users would register for the service but might only be charged for the number of message they generate.
|Overage usage||This model is a combination of the subscription and quantity application billing models. In this case a user would subscribe to a base service but would incur additional charges if their usage exceed a specific threshold.|
1. Usage processing must incorporate the concept of status since this can affect the billable state of the component being monitored. As an example, a VM may be running and generate usage records, but be in an error state. Depending on the billing policy of the provider, this may result in the user not being charged for that period.
2. Need to be able to incorporate additional metadata that is required to do bill processing: service location, service type, account hierarchy (beyond OpenStack tenant concept)
For the purpose of kick-starting the conversation, here are a few questions that we're evaluating and would value some candid discussion around:
- Does the current Ceilometer collection mechanism (generally: central agent+plugin) provide a sufficient framework to build out the variety of meters required for these use cases?
- What are the implications for storing the collected data, in terms of the number of elements collected and the ability to relate data from across multiple tenants/projects/resources?
- What are the specific obstacles to accessing the Cinder/Quantum/Nova/RedDwarf notifications and leveraging those for billing purposes?
© Copyright 2013 Hewlett-Packard Development Company