Abacus will want to support plans in its resource config (as mentioned in issue #153 https://github.com/cloudfoundry-incubator/cf-abacus/issues/153)

Starting with a basic approach, there would be a plans property(an array) added to the top-level of a resource config. The current metrics and measures properties would be moved under that plans property. This will allow them to be scoped to a plan. Despite moving metrics and measures under plans, there will be a need of a common sets of measures/metrics for plans to fall back on. This comes into play in the report for example when summary/charge functions are running on aggregated usage across all plans.

In terms of the common section, there's of a choice of leaving measures/metrics on the top level as the common/default or putting those under a different property name.

I think there's a couple of things to consider here:
-Defaulting for a plan to the common section if there is no formula defined. This may require the plan to point to the common section or logic that would automatically default to the common section (and subsequently the absolute resource config defaults that are already in place).
-If there's no plan id passed(for example some of the charge/summary calls), they would need to go this common section.

Thoughts/Concerns/Suggestions?

On Fri, Dec 11, 2015 at 4:47 PM, Benjamin Cheng <bscheng(a)us.ibm.com> wrote:

Abacus will want to support plans in its resource config (as mentioned in
issue #153 https://github.com/cloudfoundry-incubator/cf-abacus/issues/153)

Starting with a basic approach, there would be a plans property(an array)
added to the top-level of a resource config. The current metrics and
measures properties would be moved under that plans property. This will
allow them to be scoped to a plan.

+1 that makes sense to me as different plans may want to use different
measures, metrics, and metering, accumulation and aggregation functions.

Despite moving metrics and measures under plans, there will be a need of a
common sets of measures/metrics for plans to fall back on. This comes into
play in the report for example when summary/charge functions are running on
aggregated usage across all plans.

Not sure about that. AIUI with that refined design plans can now use
different metrics so usage gets aggregated at the plan level rather than
the resource level (as it wouldn't make sense to aggregate usage from
different plans metered using different metrics). That means that the
aggregation, summary and charge functions only apply to the plan level
rather than the resource level.

In terms of the common section, there's of a choice of leaving
measures/metrics on the top level as the common/default or putting those
under a different property name.

I think there's a couple of things to consider here:
-Defaulting for a plan to the common section if there is no formula
defined. This may require the plan to point to the common section or logic
that would automatically default to the common section (and subsequently
the absolute resource config defaults that are already in place).
-If there's no plan id passed(for example some of the charge/summary
calls), they would need to go this common section.

Assuming that my above statement that 'aggregation, summary and charge
functions only apply to the plan level' is correct, there's no 'common
section' anymore, so no problem with processing usage in that non-existent
common section anymore :) Makes sense?

Thoughts/Concerns/Suggestions?

- Jean-Sebastien

Not sure about that. AIUI with that refined design plans can now use
different metrics so usage gets aggregated at the plan level rather than
the resource level (as it wouldn't make sense to aggregate usage from
different plans metered using different metrics). That means that the
aggregation, summary and charge functions only apply to the plan level
rather than the resource level.


Assuming that my above statement that 'aggregation, summary and charge
functions only apply to the plan level' is correct, there's no 'common
section' anymore, so no problem with processing usage in that non-existent
common section anymore :) Makes sense?

Yes, I agree that it makes sense. We wouldn't want to deal with metrics/measures existing in specific plans mixing and matching with each other unless a real need pops up.

With the design of the scoping the measures, metrics, accumulations and
aggregations to the plan, does it mean

1) every time a service provider adds a new plan, we would have to update
the resource definition to include this new plan with the new set of
measures, metrics, accumulations and aggregations.
- even if they are the same for all the plans he onboard's especially if
they are the zero cost plans?

2)If a plan isn't on boarded, the usage submitted to that plan would not
accumulated /aggregated, even though the provisioning stub validates the
plan being submitted

Should we see this as a concern?




--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-abacus-Accommodating-for-plans-in-a-resource-config-tp3071p3139.html
Sent from the CF Dev mailing list archive at Nabble.com.

On Thu, Dec 17, 2015 at 12:37 PM, subhash <sinduri(a)us.ibm.com> wrote:

With the design of the scoping the measures, metrics, accumulations and
aggregations to the plan, does it mean

1) every time a service provider adds a new plan, we would have to update
the resource definition to include this new plan with the new set of
measures, metrics, accumulations and aggregations.

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 the plans, as the
storage for these documents is under your control (in the provisioning
service), allowing you to implement a smarter storage scheme than a single
JSON doc per resource if you'd like.

- even if they are the same for all the plans he onboard's especially if
they are the zero cost plans?

Here as well, if you decide to store the various bits of resource config in
a DB you may be able to implement some sharing, although I'd probably
suggest to look into how Javascript can be used to share bits of data
across modules in Node rather than re-inventing the wheel with a
complicated data sharing/storage model :)

2)If a plan isn't on boarded, the usage submitted to that plan would not
accumulated /aggregated, even though the provisioning stub validates the
plan being submitted

Should we see this as a concern?

Not sure I'm following what you meant here. If you're suggesting that a
production implementation of the usage validation code in the provisioning
service (really external to Abacus, although Abacus provides a minimum
sample implementation for it) should make sure that all the necessary
config bits are valid (including metering plan, rating plan, pricing, all
the usage processing functions etc), then I'd probably agree with that...
Is that what you had in mind?

- Jean-Sebastien