Open Stack

Russell Bryant <rbryant at redhat.com> wrote on 05/15/2013 01:08:43 PM:

> On 05/15/2013 12:38 AM, Michael J Fork wrote:
> >
> > 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.

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.

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

See my comments above.  In environments where these are static, it is not a
big deal.  Dynamic environments is the pain point.

> 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.

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.

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.

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.


-------------------------------------------------
Michael Fork
Architect, OpenStack Development
IBM Systems & Technology Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130516/c0d48e69/attachment.html>