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