Price plans

A price plan is the core component for defining prices. It has a set of rules and each rule defines the price to be applied for a resource in certain conditions.
With Osie having a pay-as-you-grow model, the billing engine runs periodic jobs scanning the existing price plans and calculating the price based on its rules. The resulted amount will be added to the customer's bill. i.e: for hourly rules, the job will run them every hour and will add to the bill the resulted price for that hour.

Create a price plan

From the Settings navigate to the "Price plans" section. Here you will be able to create a price plan.
A price plan consists of the following properties:

• Name: an arbitrary name you can give to your price plan
• Enabled: whether to enable the price plan. Disabled price plans will be skipped by the billing job.
• Access mode: a price plan can either be Public or Scoped
  • Public - the price plan will be applied to all the billing profiles (customers)
  • Scoped price plans should be manually assigned to billing profiles (i.e. if you want to apply different prices to different customers, you can create Scoped price plans for them)

Price plan rules

A price plan contains a list of rules. When the billing job is executed, it iterates through all the rules to calculate the price. If the rule is not applicable for a specific resource (i.e: it has defined a set of filters) it will be skipped.

Create a price plan rule

In the following example we are creating a basic rule that is charging 0.1 hourly for the v1.tiny instances. Note that 0.1 will represent the currency that was defined in the billing configuration section.

The billing job interprets the above rule as follows:

Read this rule every hour. As long as an instance exists and its instance_type is v1.tiny, then add 0.1 to the bill for this item. Then come back after another 1 hour and do the same.

Looking at the customer dashboard, when creating a server, the price will look like this:

The result is 72€ because we defined 0.1 per hour and a month is calculated for 720h (see Frequency).
This is just the projected amount for the full month so that the customers can have a better understanding about the pricing, however they will still be billed on an hourly basis in this case.

Price plan rule explained

Name

A friendly name that you can assign to this rule to be easy to recognize. It can contain a short description of what the rule actually does.

Frequency (time unit)

Can have the following values

• minute the rule will be executed every minute, but maximum 43200 times in a month. I.e if you want to charge maximum $10 per month for an instance, divide 10/43200 and set the result 0.0002314814815 in the Amount field.
• hour the rule will be executed every hour, but maximum 720 times in a month. I.e: if you want to charge maximum $10 per month for an instance, divide 10/720 and set the result 0.01388888889 in the Amount field.
• month A monthly rule will be executed in maximum 1 hour after a resource is created, and the amount is pro-rated until the end of the month for the remaining days.

Resource Type

The type of resource for which this rule should be applied. Visit the Resource Types section.
Each resource type exposes its own set of attributes which can later be used in defining a Price, Filter or a Modifier

Prices

In the Prices section you can define the actual price to be applied for the Frequency. First, you need to select a resource attribute from the list. That attribute will be then multiplied with the Amount.
Only boolean and numeric attributes are listed there, where boolean will be interpreted as 0 or 1.

A few examples:

• existence is a boolean attribute which is always 1. For the instance pricing above, the estimated cost for 1 month can be calculated as amount * existence * frequency which means 0.1 * 1 * 720 = 72.00€
• vcpus represents how many vcpus an instance has. The calculation for a hour will be amount * vcpus so if the instance has 2vCPUs will be 0.1 * 2 for 1 hour or 0.1 * 2 * 720 to estimate the cost for 1 month.

By defining multiple prices in a rule it will be a + operation and the sum result will be added to the bill for that job iteration.
i.e.: by defining both existence and vcpus prices as above, for 1 hour the job will calculate existence * 0.1 + vcpus * 0.1 = 1 * 0.1 + 2 * 0.1 = 0.3 for 1 hour.

Filters

Filters can be used to apply the calculated price only if the resource matches some criteria.
i.e: you can use filters to apply that price only for a specific instance_type, which is just an attribute of the instance resource.
Filtering is performed based on a resource's attributes. For the full list check Resource Types

Modifiers

Modifiers can be used to adjust the calculated price when the resource attributes match some criteria. It's main use case is to define discounted prices for certain scenarios.

(This section is still work in progress)