Open Stack

Sounds like one solution alright..

But - what about making quotas pluggable, like the scheduler?

This would allow for even more complex quotas, like limiting the number of
SSD backed instances across the entire cloud per tenant, while still
keeping the core implementation lean.

Kiall
On Jul 20, 2012 3:48 PM, "Eoghan Glynn" <eglynn at redhat.com> wrote:

>
> > The harder part is that we need to be able to specify
> > independent/orthogonal quota constraints on different flavors. It
> > would be really useful to be able to say basically, you can have 2TB
> > of memory from this flavor, and 4TB of memory from that flavor. This
> > would allow saying something like "you can have up to 3 1TB instances,
> > and independently have up to 3TB of small instances as well."
>
> OK, so its the "as well" aspect that's problematic here.
>
> (If it were an either-or situation as opposed to a both, then obviously
> a combination of the instances and RAM quotas would get you part of
> the way at least).
>
> So just thinking aloud, we could potentially add new per-flavor quota
> resources so that for each existing instance-type, there was the potential
> to add a new quota limiting *only* that instance type (and maybe keep
> the existing instances quotas as an over-arching limit).
>
> For example, if the following quotas where set:
>
>   instances:          100
>   instances-m1.xlarge: 10
>   instances-m1.large:  20
>   instances-m1.small:  50
>   instances-m1.tiny:  100
>
> and a user requested an additional xlarge instance, we'd first check if we
> had headroom on the instances-m1.xlarge quota and then if we also had
> headroom
> on the over-arching instances quota (before going on to check the ram &
> cores
> if necessary). Whereas, if a medium instance was requested, we would only
> check
> the overarching limit, as there is no instances-medium quota defined.
>
> This would require some change to the quotas logic, to allow the set of
> resources that may be limited by quotas to be more dynamic (currently
> we have a fairly fixed set, whereas new instance types may be defined
> at any time).
>
> Would that address your requirement?
>
> Cheers,
> Eoghan
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120720/feeeee2c/attachment.html>