Open Stack

On 05/15/2013 12:38 AM, Michael J Fork wrote:
> After coming across the no-flavors blueprint at
> _https://blueprints.launchpad.net/nova/+spec/no-flavors_ 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.  
> 
> A more detailed specification is at
> _https://wiki.openstack.org/wiki/DynamicFlavors_.
> 
> 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.

I'd like to start by focusing on whether this is a feature we want at all.

First, having a label on a pre-defined resource allocation is incredibly
handy for billing purposes.  Allowing the number of combinations to
explode in a way under the user's control makes billing and chargeback
much more complex.  Right now it's very easy to understand that flavor X
costs me Y.

I'm also skeptical with the assertion in the blueprint that managing
flavors is administratively intensive.

Right now I'm -1 on this feature.  I'm open to being convinced, though,
if others think it's useful and would like to argue their points.

> 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)
> 
> 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.
> 
> Would others find this useful?  If desired, we can post an initial
> implementation.



-- 
Russell Bryant