Open Stack

On 24/10/12 23:35 +0200, Julien Danjou wrote:
>On Wed, Oct 24 2012, Dan Dyer wrote:
>
>> 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
>
>I think that for this, you just need to add more meters on top of the
>existing one with your own user and project id information.
>
>> 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.
>
>This is probably where you should emit the meters you need.
>
>> 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.
>
>Kind of the same here, if you don't want to really bill the vm, just
>don't meter them (or ignore the meters) and emit your own meter via your
>PaaS platform to bill your customer.
>
>Or is there a limitation I miss?

If you do auto scaling you will have a similar problem. Here you
want to monitor the group (with instances comming and going) as
a logical unit. One way would be to tag the instances and then
extract the tag and send it with the metadata associated with
the meter. Then you could query the ceilometer db for that group.

(In CloudWatch this is just another "Dimension").

-Angus

>
>-- 
>Julien Danjou
>-- Free Software hacker & freelance
>-- http://julien.danjou.info



>_______________________________________________
>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