Open Stack

> Sounds like one solution alright..
> 
> But - what about making quotas pluggable, like the scheduler?

Yeah, that could certainly be a direction to head in the longer term.

The way things stand though, the decision as to which quota is being
checked against in made at the enforcement point, and the question
posed of the quotas engine is really just a dict mapping resource names
to the numbers requested (i.e. there isn't any further context provided).

So in order to allow the quotas engine ask more detailed questions
about the kind of resource required (i.e. is the instance requested
SSD-backed or whatever), we'd have provide a lot more context than we
currently do.

Cheers,
Eoghan

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