[openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)

Solly Ross sross at redhat.com
Wed May 7 18:10:11 UTC 2014


(response inline)

----- Original Message -----
> From: "Zane Bitter" <zbitter at redhat.com>
> To: openstack-dev at lists.openstack.org
> Sent: Tuesday, May 6, 2014 9:09:09 PM
> Subject: Re: [openstack-dev] [Nova] [Heat] Custom Nova Flavor creation through Heat (pt.2)
> 
> 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.)

So the simple solution is to not allow a VM that uses all of the RAM
on a given host (just don't have a RAM flavor that size), and then schedule
the VM on a host that has minimal RAM usage but high CPU usage.  This is
especially true for disk, where you may have situations where you don't
care if an otherwise large VM uses no disk (disks on network stores, etc).

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

Note that this proposal wouldn't prevent flavors from being used -- you
could still have "flavor bundles" (or something of the sort) that would
act the way current flavors do.

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

Again, what if you also have a user who needs lots of CPUs, but a relatively
small amount of RAM or disk?

> 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

But, flavors aren't (and shouldn't be) named "16G".  Realistically, it would
look more like

   nova create --cpu-flavor=large --ram-flavor=medium --disk-flavor=small

for many clouds.  Additionally, keep in mind that not everyone uses the command
line.  Developers often forget that many users will want to use horizon, and
selecting 4-64G-200G (or even large-medium-large) from a long list can be very
annoying (suppose we have 6 RAM flavors and 6 disk flavors -- that's 36 flavors
that start with "4-").

> 
> 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.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 



More information about the OpenStack-dev mailing list