<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif"><big>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. <br>
<br>
Use Case 1<br>
Service Owned Instances<br>
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.</big><small> </small><big>This
</big><big>scenario drives two requirements:<br>
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.<br>
2. The actual end user of the VM needs to be identified so usage
can be properly attributed<br>
<br>
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.<small>
</small></big></font><font face="Helvetica, Arial, sans-serif"><big>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.</big></font><font
face="Helvetica, Arial, sans-serif"><big><small><font
face="Helvetica, Arial, sans-serif"><big> From a billing
perspective these instances will have unique pricing (i.e.
premium on top of the base VM cost). </big></font></small>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.<br>
<br>
<br>
Use Case 2<br>
Multple Instances combine to make a billable "product/service"<br>
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.</big><br>
<br>
<big>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.</big></font><br>
<br>
<font face="Helvetica, Arial, sans-serif"><big>Dan Dyer<br>
HP Cloud Services<br>
aka: DanD</big></font><br>
</body>
</html>