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 : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
