I think a good deal of ceilometer's messaging and event tracking could additionally be used for event audit logging.<br><br>-Matt<br><br><div class="gmail_quote">On Wed, Oct 24, 2012 at 2:35 PM, Julien Danjou <span dir="ltr"><<a href="mailto:julien@danjou.info" target="_blank">julien@danjou.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Oct 24 2012, Dan Dyer wrote:<br>
<br>
> Use Case 1<br>
> Service Owned Instances<br>
> There are a set of use cases where a service is acting on behalf of a user,<br>
> the service is the owner of the VM but billing needs to be attributed to the<br>
</div>> end user of the system.This scenario drives two requirements:<br>
<div class="im">> 1. Pricing is similar to base VM's but with a premium. So the type of<br>
> service for a VM needs to be identifiable so that the appropriate pricing<br>
> can be applied.<br>
> 2. The actual end user of the VM needs to be identified so usage can be<br>
> properly attributed<br>
<br>
</div>I think that for this, you just need to add more meters on top of the<br>
existing one with your own user and project id information.<br>
<div class="im"><br>
> As an example, in some of our PAAS use cases, there is a service controller<br>
> running on top of the base VM that maintains the control and and manages the<br>
> customer experience. The idea is to expose the service and not have the<br>
> customer have to (or even be able to) manipulate the virtual machine<br>
> directly. So in this case, from a Nova perspective, the PAAS service owns<br>
> the VM and it's tenantID is what is reported back in events. The way we<br>
> resolve this is to query the service controller for meta data about that<br>
> instances they own. This is stored off in a separate "table" and used to<br>
> determine the real user at aggregation time.<br>
<br>
</div>This is probably where you should emit the meters you need.<br>
<div class="im"><br>
> Use Case 2<br>
> Multple Instances combine to make a billable "product/service"<br>
> In this use case, a service might consist of several VM's, but the actual<br>
> number does not directly drive the billing.  An example of this might be a<br>
> redundant service that has a primary and two backup VM's that make up a<br>
> deployment. The customer is charged for the service, not the fact that there<br>
> are 3 VM's running. Once again, we need meta data that is able to describe<br>
> this relationship so that when the billing records are processed, this<br>
> relationship can be identified and billed properly.<br>
<br>
</div>Kind of the same here, if you don't want to really bill the vm, just<br>
don't meter them (or ignore the meters) and emit your own meter via your<br>
PaaS platform to bill your customer.<br>
<br>
Or is there a limitation I miss?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Julien Danjou<br>
-- Free Software hacker & freelance<br>
-- <a href="http://julien.danjou.info" target="_blank">http://julien.danjou.info</a><br>
</font></span><br>_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br></blockquote></div><br>