<html><body>
<p><tt><font size="2">Jesse Pretorius <jesse.pretorius@gmail.com> wrote on 05/16/2013 05:45:40 AM: </font></tt><br>
<tt><font size="2">></font></tt><br>
<tt><font size="2">> > Right now I'm -1 on this feature. I'm open to being convinced,<br>
> > though, if others think it's useful and would like to argue their<br>
> > points.</font></tt><br>
<tt><font size="2">> I definitely don't like the approach of creating actual flavors<br>
> dynamically, as is currently being proposed.</font></tt><br>
<tt><font size="2">> <br>
> Happy with that view. What I'm hoping for is that we can stimulate <br>
> thought on two things:</font></tt><br>
<tt><font size="2">> <br>
> 1) Can we facilitate, perhaps with a little smoke and mirrors as <br>
> suggested by me on the whiteboard of the Blueprint, a way that <br>
> through Horizon the selection appears to be more dynamic... even if <br>
> it isn't actually dynamic? This, of course, would be an alternative <br>
> blueprint for the Horizon project and wouldn't need any changes in nova.</font></tt><br>
<tt><font size="2">> Perhaps it's worth clarifying that the problem we specifically are <br>
> trying to get away from here is something we're finding in our <br>
> private cloud deployments - the flavor list is getting impractically<br>
> large for Horizon's drop-down box selection.</font></tt><br>
<br>
<tt><font size="2">I understand your motivation, but would really like this to exist at the Nova API level as I believe it has value to those not using Horizon. </font></tt><br>
<tt><font size="2"> <br>
> 2) Can we, with Michael's suggested approach, facilitate changes in <br>
> instance specifications in a relatively simple manner? We know that <br>
> typical cloud instances should be throw-away servers with automated <br>
> software deployment and configuration. However, as Openstack gets <br>
> used more and more in Private Cloud implementations and other <br>
> typically IaaS deployments, the need for instance specification <br>
> changes will become more and more important.</font></tt><br>
<br>
<tt><font size="2">Agreed cloud instances should be considered throw-away as a best-practice, but I view that as a design pattern to tolerate failure and not a reason to force create/destroy of otherwise good resources. In non-failure scenarios, I don't want to destroy a built, configured, and functioning system just to add a little more RAM or another processor.</font></tt><br>
<br>
<tt><font size="2">I would also expand on the need for instance specification changes becoming more important as the upper layers get more intelligent, metering is done at the application level (vs IaaS resource), and the goal shifts to maximizing utilization vs just allocation.</font></tt><br>
<br>
<font size="2" face="sans-serif">Michael<br>
<br>
-------------------------------------------------<br>
Michael Fork<br>
Architect, OpenStack Development<br>
IBM Systems & Technology Group</font></body></html>