Open Stack

Excerpts from Solly Ross's message of 2014-05-05 08:23:41 -0700:
> Just to expand a bit on this, flavors are supposed to be the lowest level of granularity,
> and the general idea is to round to the nearest flavor (so if you have a VM that requires
> 3GB of RAM, go with a 4GB flavor).  Hence, in my mind, it doesn't make any sense to create
> flavors on the fly; you should have enough flavors to suit your needs, but I can't really
> think of a situation where you'd need so much granularity that you'd need to create new
> flavors on the fly (assuming, of course, that you planned ahead and created enough flavors
> that you don't have VMs that are extremely over-allocated).

I agree with the conclusion you're arguing for, but it is a bit more
complex than that. Flavor defines at least three things, and possibly 4:
RAM, root disk, and vcpu, with an optional ephemeral disk. Because of
that, the matrix of possibilities can get extremely large.

Consider if you segment RAM as 1GB, 4GB, 8GB, 16GB, vcpu as 1, 2, 4,
8, and root disk as 10G, 50G, 100G, 1T. Your matrix is now 4³, 64
flavors. If you've never heard of "the paradox of choice", consumers
are slowed down by having too many choices. So less flavors will not
only make your resource consumption easier to optimize, it will help
new users move forward with more certainty.

But the reality is, nobody needs an 8 CPU, 1T, 1GB flavor. Likewise,
nobody needs a 1 CPU 16GB 10G server. Both are missing the mark with
the common workloads. And a lot are filled in by higher level services
like Trove, LBaaS, Swift, etc.

So realistically, having 20-30 flavors, with groupings around the
combinations users demand, is a known pattern that seems to work well.
If a user has a workload that is poorly served by any of these, it
probably makes the most sense for them to over-buy and demand a better
sized flavor from the provider. Dynamically allocating flavors is just
going to complicate things for everybody.

That said, if Nova supports it, Heat should too.