<html><body>
<p><font size="2" face="sans-serif">After coming across the no-flavors blueprint at </font><a href="https://blueprints.launchpad.net/nova/+spec/no-flavors"><font size="3" color="#0000FF" face="serif"><u>https://blueprints.launchpad.net/nova/+spec/no-flavors</u></font></a><font size="3" face="serif"> </font><font size="2" face="sans-serif">and exchanging a few e-mails with the author, we thought it would be good to take Russell's advice and take to the mailing list for feedback. </font><br>
<br>
<font size="2" face="sans-serif">A more detailed specification is at </font><a href="https://wiki.openstack.org/wiki/DynamicFlavors"><font size="3" color="#0000FF" face="serif"><u>https://wiki.openstack.org/wiki/DynamicFlavors</u></font></a><font size="3" face="serif">.</font><br>
<br>
<font size="2" face="sans-serif">To summarize, this proposal is about allowing the create server and resize server APIs to take the same flavor element as used in create flavor in addition to a flavorRef element. The use of the flavor element should be controlled by policy and by default be restricted to admins to keep with current behavior. Deployments that wish to expose this to non-admins would have to make an explicit policy change.</font><br>
<br>
<font size="2" face="sans-serif">From an implementation standpoint, extensions would be added to the APIs to handle the flavor element. When encountered, a MD5 hash is computed on the flavor data structure and a matching hash looked for among existing flavors. If no match is found, a new, non-public flavor is created. The flavor element is then replaced with a flavorRef element and processing continues as-is today. This implementation should be non-invasive and have minimal impact to existing code paths (other than to refactor create flavor to re-use in all 3 places)</font><br>
<font size="2" face="sans-serif"><br>
One open question is if we need more constraints on the values other than overall usage being constrained by quota and the size of any single resource by what the scheduler can deploy. One proposal is to add min, max, and/or step values to be enforced by the extension. However, one side effect is that it adds complexity by requiring a new API to convey those limits.</font><br>
<br>
<font size="2" face="sans-serif">Would others find this useful? If desired, we can post an initial implementation.</font><br>
<font size="2" face="sans-serif"><br>
Michael<br>
<br>
-------------------------------------------------<br>
Michael Fork<br>
Architect, OpenStack Development<br>
IBM Systems & Technology Group</font></body></html>