<p>Sounds like one solution alright..</p>
<p>But - what about making quotas pluggable, like the scheduler?</p>
<p>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.</p>
<p>Kiall</p>
<div class="gmail_quote">On Jul 20, 2012 3:48 PM, "Eoghan Glynn" <<a href="mailto:eglynn@redhat.com">eglynn@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> The harder part is that we need to be able to specify<br>
> independent/orthogonal quota constraints on different flavors. It<br>
> would be really useful to be able to say basically, you can have 2TB<br>
> of memory from this flavor, and 4TB of memory from that flavor. This<br>
> would allow saying something like "you can have up to 3 1TB instances,<br>
> and independently have up to 3TB of small instances as well."<br>
<br>
OK, so its the "as well" aspect that's problematic here.<br>
<br>
(If it were an either-or situation as opposed to a both, then obviously<br>
a combination of the instances and RAM quotas would get you part of<br>
the way at least).<br>
<br>
So just thinking aloud, we could potentially add new per-flavor quota<br>
resources so that for each existing instance-type, there was the potential<br>
to add a new quota limiting *only* that instance type (and maybe keep<br>
the existing instances quotas as an over-arching limit).<br>
<br>
For example, if the following quotas where set:<br>
<br>
  instances:          100<br>
  instances-m1.xlarge: 10<br>
  instances-m1.large:  20<br>
  instances-m1.small:  50<br>
  instances-m1.tiny:  100<br>
<br>
and a user requested an additional xlarge instance, we'd first check if we<br>
had headroom on the instances-m1.xlarge quota and then if we also had headroom<br>
on the over-arching instances quota (before going on to check the ram & cores<br>
if necessary). Whereas, if a medium instance was requested, we would only check<br>
the overarching limit, as there is no instances-medium quota defined.<br>
<br>
This would require some change to the quotas logic, to allow the set of<br>
resources that may be limited by quotas to be more dynamic (currently<br>
we have a fairly fixed set, whereas new instance types may be defined<br>
at any time).<br>
<br>
Would that address your requirement?<br>
<br>
Cheers,<br>
Eoghan<br>
<br>
_______________________________________________<br>
Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
</blockquote></div>