Hi, metrics (the rest basically) Your proposal looks good to me. Piotr, Kevin and Raj and I had several design discussions on this topic in the last few days and we've come up with a few more ideas on

Hi Chaskin, Thanks for sharing your thoughts! I'll try to address some of your questions: which of the types of content based filtering are required to express what we need while maintaining a scalabl

Hi Hristo, This looks really good! +1 to merging this as a new module in master, and continuing the work there, as then we can all work together on creating the abstraction layer that'll select betwee

Kevin, This looks like a nice summary to me! I've added a few comments inline below. Thanks! - Jean-Sebastien The id of the definition of the measures, metrics and metering formula Yes, and the pricin

It is correct that the account service returns the list of orgs but that's for a different purpose. AIUI here we're going to reuse and extend the current provisioning service endpoint (used to validat

I'd like to propose a variation of this. Given (org_id, space_id, consumer_id, resource_id, provisioning_plan_id, resource_instance_id and usage_time), return: (a) a 404 indicating an invalid/not_foun

Hi Hristo, This looks pretty good! Thanks for this contribution! I'm going to take a closer look at your module today. ... I'm happy to rename the COUCHDB env variable to just DB to allow for other da

I'd vote for a clean programming model here with 2 different Javascript functions implementing the 2 different mathematical functions you think you need. Thoughts? - Jean-Sebastien

Yes, every time you want to add a new plan, you need to update the list of plans under the resource (to add that plan). That doesn't necessarily mean updating a single *stored* document containing all

I was thinking about maybe combining the provisioning and account APIs together to allow the collector service to validate and enrich incoming usage with the metering_plan, rating_plan, account_id and

I'm happy to announce the availability of CF Abacus v0.0.4 (incubating). Abacus provides usage metering and aggregation for Cloud Foundry services and app runtimes. I'd like to thank the Abacus commit

Ben, Assk and I also discussed this in the last few days and from these discussions it looks like you may need to distinguish (a) the plan used by the customer to provision a service (e.g. small datab

+1 that makes sense to me as different plans may want to use different measures, metrics, and metering, accumulation and aggregation functions. Not sure about that. AIUI with that refined design plans

Thanks Piotr, aggregation within consumer by the resource Id is also something we would like to access - for example to determine that application used two different version of node. OK so then that m

It depends if you still want usage aggregation at both the resource_id and resource_type_id levels (more changes as that'll add another aggregation level to the reports) or if you only need aggregatio

Hi Daniel, Is that related to Github issue #38? https://github.com/cloudfoundry-incubator/cf-abacus/issues/38 Thanks - Jean-Sebastien

Hi all, Here's an update on this topic and the design discussions Assk, Ben and I had in the last few days: I'll start with a description of the problem we're trying to solve here: Abacus currently co

I just wanted to follow up on this. Github 110 is now closed as we've finished removing explicit references to regions in the Abacus API in favor of a more generic namespace/scoping mechanism. With th

Any update at all? Thanks - Jean-Sebastien jsdelfino(a)gmail.com> wrote:

Yes, that's why I was suggesting one doc per registration keyed by trigger criteria. I thought a bit more about this. We could set a timeout (using our circuit breaker module for example) causing slow