>
>
>
> (BTW, I'd like to point out the Boson proposal and thread…)
>
Good point, we also need to think through how distributed quotas will work
across multiple cells. I can see a lot of overlap between these two use
cases: I want to limit users to a specific quota for a specific flavor and
I wa
> > Would that address your requirement?
>
> I think so. If these acted as a hard limit in conjunction with
> existing quota constraints, I think it would do the trick.
I've raised this a nova blueprint, so let's see if it gets any traction:
https://blueprints.launchpad.net/nova/+spec/flavo
On Fri, 2012-07-20 at 15:59 +0100, Kiall Mac Innes wrote:
> But - what about making quotas pluggable, like the scheduler?
They are; see the "quota_driver" configuration option. However…
> This would allow for even more complex quotas, like limiting the
> number of SSD backed instances across the
On Fri, Jul 20, 2012 at 9:59 AM, Kiall Mac Innes wrote:
> 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, w
On Fri, Jul 20, 2012 at 9:42 AM, Eoghan Glynn 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 mem
On Fri, Jul 20, 2012 at 4:18 PM, Eoghan Glynn wrote:
>
> Yeah, that could certainly be a direction to head in the longer term.
>
Sure - I doubt, even if there was somebody willing to start an
implementation of this today, that it would land in F!
I suppose I'm suggesting that: with the possibil
> 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, an
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,
> 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 l
On Fri, Jul 20, 2012 at 4:38 AM, Eoghan Glynn wrote:
> Hi Narayan,
>
> I had the idea previously of applying a "weighting function" to the
> resource usage being allocated from the quota, as opposed to simply
> counting raw instances.
>
> The notion I had in mind was more related to image usage i
> We're running a system with a really wide variety of node types. This
> variety (nodes with 24GB, 48GB, GPU nodes, and 1TB mem nodes) causes
> some real trouble with quotas. Basically, for any tenant that is going
> to use the large memory nodes (even in smaller slices), we need to set
> quotas
We're running a system with a really wide variety of node types. This
variety (nodes with 24GB, 48GB, GPU nodes, and 1TB mem nodes) causes
some real trouble with quotas. Basically, for any tenant that is going
to use the large memory nodes (even in smaller slices), we need to set
quotas that are hi
12 matches
Mail list logo
