Cost engine RFC

Scott Seago sseago at redhat.com
Fri Oct 26 15:20:40 UTC 2012


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

> 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.
>




More information about the aeolus-devel mailing list