Open Stack

On Sat, Apr 5, 2014 at 3:22 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> On Fri, 2014-04-04 at 20:39 -0500, Narayan Desai wrote:
> >> If you're interested in quotas, we have a completely different problem
> > with quotas that is a real showstopper for us. We have a really large
> > dynamic range in resource quantities for our different instance types.
> > (for example, we have 3 orders of magnitudes in the range of memory
> > configurations). This makes quotas pretty useless for us as they are
> > currently implemented, since you can't represent limits for these
> > different kinds of resources in the same quota.
>
> Why can't you? The resource is the memory, CPU, and disk used, not the
> instance type.
>
> Honestly, I think that this is a user-interface thing, not a quota
> management thing. In other words, have the quota-management UI show some
> translation help-text. For the user, it would be something like "you
> have room for X m2.xlarge instances left". For an admin it would be
> something like "this quota allocation represents X m2.xlarge instances".


I think that this assumption is the reason that we have the quota system
that we do. A resource like 1GB of memory isn't comparable across all kinds
of resources. It is if you have a simple hardware configuration with
relatively uniform hardware configurations, but heterogeneity causes this
not to work.

For example, 1GB of memory on a 24 GB system is way different than 1GB of
memory on a 2TB system. The costs are different, the resource allocation
considerations are different, etc. A model that assumes uniformity means
that you can't do anything sensible when resource costs and considerations
aren't uniform across your system.

While keying off of instance types isn't perfect, and certainly doesn't
give you the model that you'd like, you can make things work based on an
implicit resource model when using instances that you can't do through
resource reductionism.
 -nld
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20140407/9d2dc5b4/attachment.html>