Open Stack

+1 for both of these use cases
On Oct 24, 2012 5:06 PM, "Dan Dyer" <dan.dyer00 at gmail.com> 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     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121024/d43883da/attachment.html>