← Back to team overview

openstack team mailing list archive

Re: [ceilometer] Potential New Use Cases

 

I don't think its just a matter of adding more meters or events for a couple of reasons: 1. In many cases the metadata I am referring to comes from a different source than the base usage data. Nova is still emitting its normal events, but we get the service/user mapping from a different source. I would not characterize this data as usage metrics but more data about the system relationships. 2. in the multiple VM case, we need to have the relationships specified so that we can ignore the proper VM's. There has also been talk of hybrid billing models that charge for some part of the VM usage as well as other metrics. Once again we need a way to characterize the relationships so that processing can associate and filter correctly.

Dan

On 10/24/2012 3:35 PM, 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?




Follow ups

References