+1 for both of these use cases On Oct 24, 2012 5:06 PM, "Dan Dyer" <[email protected]> wrote:
> 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 > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
