<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">> I'm also skeptical with the assertion in the blueprint that managing<br>
> flavors is administratively intensive.<br>
<br>
</div>I think that is probably true for Nova being applied to non-cloudy<br>
deployment scenarios. However, that only points (IMHO) to why that<br>
shouldn't be done in the first place.<br></blockquote><div><br></div><div style>Fair point. To some degree the background that led me to put the initial blueprint down came from exposure to feature requests from private cloud deployments. That said, perhaps my initial take on getting rid of flavors altogether was a little radical and my discussion with Michael and this discussion is proving valuable to temper that radicality into practicality.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> 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.<br>
</div>I definitely don't like the approach of creating actual flavors<br>
dynamically, as is currently being proposed.<br></blockquote><div><br></div><div style>Happy with that view. What I'm hoping for is that we can stimulate thought on two things:</div><div style><br></div><div style>1) Can we facilitate, perhaps with a little smoke and mirrors as suggested by me on the whiteboard of the Blueprint, a way that through Horizon the selection appears to be more dynamic... even if it isn't actually dynamic? This, of course, would be an alternative blueprint for the Horizon project and wouldn't need any changes in nova.<br>
</div><div style><div>Perhaps it's worth clarifying that the problem we specifically are trying to get away from here is something we're finding in our private cloud deployments - the flavor list is getting impractically large for Horizon's drop-down box selection.</div>
</div><div style><br></div><div style>2) Can we, with Michael's suggested approach, facilitate changes in instance specifications in a relatively simple manner? We know that typical cloud instances should be throw-away servers with automated software deployment and configuration. However, as Openstack gets used more and more in Private Cloud implementations and other typically IaaS deployments, the need for instance specification changes will become more and more important.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If I recall correctly, part of the reason we (I) made the move to<br>
storing flavor information in system_metadata was so that we could have<br>
fine-grained resizes, if desired. Assuming a deployer wanted to sell<br>
small upgrades, like buying more memory without needing more disk<br>
space, etc.<br></blockquote><div><br></div><div style>Quite right. Often it'll be a change of one element.</div></div></div></div>