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

Solly Ross sross at redhat.com
Mon May 5 17:01:12 UTC 2014


If you actually have 64 flavors, though, and it's overwhelming
your users, it would be pretty trivial to implement a "flavor
recommender" where you input your requirements and it pops out
the nearest flavor.  That being said, I do think you're right
that you can probably mitigate flavor explosion by trimming out
the outlier flavors.  20-30 flavors is still a bit much, but with
some clever naming, the burden of choosing a flavor can be lessened.

Additionally, if this is all for the purpose of orchestration,
we have a computer dealing with choosing the correct flavor,
and if your computer has a problem dealing with a choice between 64
(or even 512) different flavors, perhaps it's time to upgrade :-P.

Best Regards,
Solly Ross

----- Original Message -----
From: "Clint Byrum" <clint at fewbar.com>
To: "openstack-dev" <openstack-dev at lists.openstack.org>
Sent: Monday, May 5, 2014 12:28:58 PM
Subject: Re: [openstack-dev] [Nova][Heat] Custom Nova Flavor creation	through Heat (pt.2)

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.

_______________________________________________
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