I think a good deal of ceilometer's messaging and event tracking could additionally be used for event audit logging.
-Matt On Wed, Oct 24, 2012 at 2:35 PM, Julien Danjou <jul...@danjou.info> 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? > > -- > Julien Danjou > -- Free Software hacker & freelance > -- http://julien.danjou.info > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
