Open Stack

On 05/05/14 13:40, Solly Ross wrote:
> One thing that I was discussing with @jaypipes and @dansmith over
> on IRC was the possibility of breaking flavors down into separate
> components -- i.e have a disk flavor, a CPU flavor, and a RAM flavor.
> This way, you still get the control of the size of your building blocks
> (e.g. you could restrict RAM to only 2GB, 4GB, or 16GB), but you avoid
> exponential flavor explosion by separating out the axes.

Dimitry and I have discussed this on IRC already (no-one changed their 
mind about anything as a result), but I just wanted to note here that I 
think even this idea is crazy.

VMs are not allocated out of a vast global pool of resources. They're 
allocated on actual machines that have physical hardware costing real 
money in fixed ratios.

Here's a (very contrived) example. Say your standard compute node can 
support 16 VCPUs and 64GB of RAM. You can sell a bunch of flavours: 
maybe 1 VCPU + 4GB, 2 VCPU + 8GB, 4 VCPU + 16GB... &c. But if (as an 
extreme example) you sell a server with 1 VCPU and 64GB of RAM you have 
a big problem: 15 VCPUs that nobody has paid for and you can't sell. 
(Disks add a new dimension of wrongness to the problem.)

The insight of flavours, which is fundamental to the whole concept of 
IaaS, is that users must pay the *opportunity cost* of their resource 
usage. If you allow users to opt, at their own convenience, to pay only 
the actual cost of the resources they use regardless of the opportunity 
cost to you, then your incentives are no longer aligned with your 
customers. You'll initially be very popular with the kind of customers 
who are taking advantage of you, but you'll have to hike prices across 
the board to make up the cost leading to a sort of dead-sea effect. A 
Gresham's Law of the cloud, if you will, where bad customers drive out 
good customers.

Simply put, a cloud allowing users to define their own flavours *loses* 
to one with predefined flavours 10 times out of 10.

In the above example, you just tell the customer: bad luck, you want 
64GB of RAM, you buy 16 VCPUs whether you want them or not. It can't 
actually hurt to get _more_ than you wanted, even though you'd rather 
not pay for it (provided, of course, that everyone else *is* paying for 
it, and cross-subsidising you... which they won't).

Now, it's not the OpenStack project's job to prevent operators from 
going bankrupt. But I think at the point where we are adding significant 
complexity to the project just to enable people to confirm the 
effectiveness of a very obviously infallible strategy for losing large 
amounts of money, it's time to draw a line.


By the way, the whole theory behind this idea seems to be that this:

   nova server-create --cpu-flavor=4 --ram-flavour=16G --disk-flavor=200G

minimises the cognitive load on the user, whereas this:

   nova server-create --flavor=4-64G-200G

will cause the user's brain to explode from its combinatorial 
complexity. I find this theory absurd.

In other words, if you really want to lose some money, it's perfectly 
feasible with the existing flavour implementation. The operator is only 
ever 3 for-loops away from setting up every combination of flavours 
possible from combining the CPU, RAM and disk options, and can even 
apply whatever constraints they desire.


All that said, Heat will expose any API that Nova implements. Choose wisely.

cheers,
Zane.