<html><body>
<p><tt><font size="2">Russell Bryant <rbryant@redhat.com> wrote on 05/15/2013 01:08:43 PM:<br>
<br>
> On 05/15/2013 12:38 AM, Michael J Fork wrote:<br>
> > <br>
> > To summarize, this proposal is about allowing the create server and<br>
> > resize server APIs to take the same flavor element as used in create<br>
> > flavor in addition to a flavorRef element. The use of the flavor<br>
> > element should be controlled by policy and by default be restricted to<br>
> > admins to keep with current behavior. Deployments that wish to expose<br>
> > this to non-admins would have to make an explicit policy change.<br>
> <br>
> I'd like to start by focusing on whether this is a feature we want at all.<br>
> <br>
> First, having a label on a pre-defined resource allocation is incredibly<br>
> handy for billing purposes. Allowing the number of combinations to<br>
> explode in a way under the user's control makes billing and chargeback<br>
> much more complex. Right now it's very easy to understand that flavor X<br>
> costs me Y.<br>
</font></tt><br>
<tt><font size="2">Completely agreed that flavors are incredibly handy for a lot of purposes, chargeback and billing included; I have no desire to see them go away or even to change.</font></tt><br>
<tt><font size="2"> <br>
> I'm also skeptical with the assertion in the blueprint that managing<br>
> flavors is administratively intensive.<br>
</font></tt><br>
<tt><font size="2">See my comments above. In environments where these are static, it is not a big deal. Dynamic environments is the pain point. </font></tt><br>
<tt><font size="2"><br>
> Right now I'm -1 on this feature. I'm open to being convinced, though,<br>
> if others think it's useful and would like to argue their points.<br>
</font></tt><br>
<tt><font size="2">For organizations where chargeback and billing are extremely important (e.g. Public Clouds), I don't expect dynamic flavors to be available to end-users and wouldn't be surprised to see the policy modified to disable completely with only a select subset of admins being able to access the traditional flavor creation path. </font></tt><br>
<br>
<tt><font size="2">However, not all installations (or, at a lower level, accounts) have chargeback and billing at the IaaS resource level, e.g. Cloud Foundry (or other PaaS) application that meters and charges by the request. In this environment, I would want to give rights to the account that allowed fine control over resource allocations, e.g. ability to just RAM when needed (preferably in-line w/o requiring a restart). Outside of that one account, I want to retain my traditional flavor and billing/chargeback structure.</font></tt><br>
<br>
<tt><font size="2">When viewing OpenStack as a next-generation platform for developing scalable solutions, the flexibility to allow some access to finely control allocations seems very valuable, especially as our ability to analyze and respond to workload changes improves. Imagine this feature coupled with in-place resizes that allow the addition/removal of CPU and RAM on-demand to scale realtime and the possibilities.</font></tt><br>
<font size="2" face="sans-serif"><br>
<br>
-------------------------------------------------<br>
Michael Fork<br>
Architect, OpenStack Development<br>
IBM Systems & Technology Group</font></body></html>