Open Stack

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