openstack team mailing list archive

[Matt Joyce <matt.joyce@xxxxxxxxxxxxxxxx>]

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 <julien@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>