Open Stack

Let's imagine that the service that launch instances can tag the
instance with:
a) a common service identifier (constant)
b) a uuid unique for each "Unit" of the service
such as <constant>:<uuid>

If that tag is passed onto the events which ceilometer stores in its
entirety as meta, I do not see what the difficulty would be for the
rating engine to be able to reconcile the information to handle your 2
use cases.  Am I missing something?

Nick

On 10/25/2012 12:03 AM, Dan Dyer wrote:
> 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?
>>
> 
> 
> _______________________________________________
> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121025/7a2cf6af/attachment.sig>