Cost engine RFC

Martin Povolny mpovolny at redhat.com
Fri Oct 26 15:59:15 UTC 2012


On Fri, Oct 26, 2012 at 11:20:40AM -0400, Scott Seago wrote:
> On 10/26/2012 11:06 AM, Martin Povolny wrote:
> >
> >Notes and further work
> >----------------------
> >
> >The entering of cost estimates for chargeables in Conductor has to be detailed.
> >
> >In the first iteration we care only about backend hardware profile so we have
> >to provide a list of available hardware profiles per cloud provider with the
> >cost and provide a form to enter the costs.
> This isn't an exhaustive commentary on the proposal, but I wanted to make
> sure that the HWP variability is taken into account here in this design. A
> HWP can be static (like on ec2 -- a given HWP has a precise amount of ram
> and CPU), or dynamic -- all HWP params can be any one of three types:
>  a) fixed (exactly 1 CPU)
>  b) enum (1 or 2 CPUs; i386 or x8_64; etc)
>  c) range (2-4 CPUs; 512 MB-32 GB)
> 
> In fact, a provider with a single HWP with range params can cover a greater
> range of possible sizes than a provider with a long list of static HWPs.
> 
> The other confusing factor is that HWP storage doesn't necessarily mean the
> same thing across providers.
> 
> The point is we can't simply assign a single cost factor to a hardware
> profile -- that won't work for providers that primarily handle sizing
> differences by varying HWP params rather  than switching to a completely
> different hardware profile. Instead, we may need to model cost in terms of
> cost per CPU unit+cost for memory -- it's also possible that it's something
> more complex -- a per-HWP cost, per CPU cost above some baseline CPU value,
> per MB memory cost above some baseline memory value, and the same with
> storage. That way we handle static HWPs easily enough -- the
> per-CPU/memory/storage cost bits can just be left alone, but the variable
> HWPs are handled too.
> 
> Scott

I see the need to address various types of things the user might be
billed for. Therefor I came with the concept of "chargeable".

In the first iteration the only chargeable type is the hardware profile
as at EC2.

Next, the chargeable might be storage attached, IP assigned.

I can address the specific case you come up with either this way:

1) the hardware_profile chargeable would cost 0 
2) the CPU and RAM would be separate chargeables with their specific costs

Also I would be grateful if you can point me to a cloud provider that
has a billing schema that you suggest so that I can take a look and
verify my ideas.

One more important thing has to be said clearly: We aim for cost
estimate not for billing. Getting the numbers right would be almost
impossible given the many variables.

> 
> >There's no official API for getting cost information.
> >
> >EC2 has an unofficial page that serves basic cost information in JSON. EC2 also
> >provides billing information in form of CSV files. Further means of retrieving
> >cost and billing information have to be researched.
> >
> >We probably should include some values from the most popular providers in the
> >installation packages.
> >
> 

-- 
Martin Povolny <mpovolny at redhat.com>
tel. +420 777714458



More information about the aeolus-devel mailing list