Excerpts from Solly Ross's message of 2014-05-05 10:01:12 -0700: > 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. >
When starting with nothing, users are pretty much going to have to guess. They'll have 64 things to choose from. The computer only gets involved when you have data. A piece of software which takes measurements of resource constraints of your application, and understands how to then choose a flavor is not exactly simple. One also needs business rules, as sometimes you may want to accept being resource constrained in exchange for reducing cost. Though it would be a pretty cool feature if one could simply run an agent on their vm and it would be able to identify the flavor that would be most efficient. :) _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
