On 10/26/2012 11:59 AM, Martin Povolny wrote:
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.
So the main one here would be RHEV and vSphere -- the supported "private
cloud" types. Internally, they don't use "hardware profiles" as such --
they take RAM and CPU values. So when deltacloud (and thus Conductor)
exposes these providers, it's done with a single hardware profile that
gets filled in at launch-time with the variable values for CPU and memory.
And yes, I understand we're talking about 'ballpark' cost estimates not
actual billed costs. The idea is that, among other things, we need a
notion of relative cost so the provider selection algorithms can take
this into account when deciding where to launch. However, we need at
least rudimentary support for including CPU and memory differences,
otherwise we'll list all RHEV instances at the same approximate cost,
whether they have 1 GB of RAM or 32!
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.
>>