Open Stack

In some cases, the service controller is actually running inside a VM. 
It would not have access to the internals of the VM's. It maintains its 
metadata separately from the Nova infrastructure.

DD

On 10/25/2012 2:25 AM, Nick Barcet wrote:
> 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
>
>
>
> _______________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20121101/bd4d7afb/attachment.html>