openstack team mailing list archive

[Dan Dyer <dan.dyer00@xxxxxxxxx>]

Based on a discussion with Doug at the Summit, I would like to propose a 
couple of new use cases for Ceilometer. As background, up until now, the 
usage data that Ceilometer collects could be considered atomic in the 
sense that everything needed to understand/process the information could 
be contained in a single generated event. We have identified some use 
cases that will require additional meta data about the source and/or 
type of the event so that later processing can be performed.

Use Case 1
Service Owned Instances
There are a set of use cases where a service is acting on behalf of a 
user, the service is the owner of the VM but billing needs to be 
attributed to the end user of the system.This scenario drives two 
requirements:
1. Pricing is similar to base VM's but with a premium. So the type of 
service for a VM needs to be identifiable so that the appropriate 
pricing can be applied.
2. The actual end user of the VM needs to be identified so usage can be 
properly attributed

As an example, in some of our PAAS use cases, there is a service 
controller running on top of the base VM that maintains the control and 
and manages the customer experience. The idea is to expose the service 
and not have the customer have to (or even be able to) manipulate the 
virtual machine directly. So in this case, from a Nova perspective, the 
PAAS service owns the VM and it's tenantID is what is reported back in 
events. The way we resolve this is to query the service controller for 
meta data about that instances they own. This is stored off in a 
separate "table" and used to determine the real user at aggregation 
time.Note that in theory you could do this in the agent as part of 
collection, but we have found that this is very expensive and scales 
best if the actual substitution is delayed until the latest point 
possible (which at that point potentially means there are less records 
to process or can be better handled with parallel processing using 
something like MapReduce.From a billing perspective these instances will 
have unique pricing (i.e. premium on top of the base VM cost). Part of 
the aggregation process is to substitute the billable account for the 
service account and identify the service type so that proper billing can 
be applied. We would like to see the Ceilometer data model expanded to 
store this kind of metadata.


Use Case 2
Multple Instances combine to make a billable "product/service"
In this use case, a service might consist of several VM's, but the 
actual number does not directly drive the billing.  An example of this 
might be a redundant service that has a primary and two backup VM's that 
make up a deployment. The customer is charged for the service, not the 
fact that there are 3 VM's running. Once again, we need meta data that 
is able to describe this relationship so that when the billing records 
are processed, this relationship can be identified and billed properly.

Both of these use cases point to a general need to be able to store 
meta-data that will allow the usage processing logic to identify 
relationships between VM's and provide additional context for 
determining billing policy.

Dan Dyer
HP Cloud Services
aka: DanD