Skip to content
This repository has been archived by the owner on Feb 27, 2023. It is now read-only.

Price Plan

Sergio Ocón edited this page May 23, 2018 · 2 revisions

Price Plan

A price plan represents the full list of costs that can be applied to the input. A price plan consists on a set of rates and the conditions to apply them

The process

When using a price plan to rate, the input will be an inventory of objects and a list of measures for those objects. For each element in the input, the price plan calculate_cost will find those rates that apply (i.e. rates for EC2 in US-East(Ohio) for RHEL on-demand. Once the rates that applied are found, the price plan will call all of them, in turn, with the value and the context associated. Any calculation at the end of the period is added and the result is given back to the customer.

Screener

Every object that is rated is are created with a context. That context can be anything (i.e. variables to use in rating, tier values, tags, something in the account, etc). In order to be able to filter based on tags or rates, we compare the context with the rate screener.

  1. If screener is fully included in the context, the rate is used (i.e. the tag is present). For instance, if the screener specifies that the rate is for RHEL, US-East, only rates for that region will be considered.
  2. If screener is not fully included in the context, the rate is not used (i.e. the tag is not present)
  3. In a group of rates, one of them can be defined as default, and be used whenever there is no other one applied.

Let's imagine that the user wants to set up different rates for storage types: "SSD", "HA", "normal". The user would need to define 3 rates with the same input and type but with different screeners, like one that includes storage-type: "SSD", another with storage-type: "HA", and a third one with storage-type: "normal".

Rating will evaluate the event against the screener, and if the event is marked "normal", only the storage-type: "normal"rate would be applied.