On Fri, 6 Jan 2017 12:15:34 -0500, William M Edmonds wrote:
Why would someone need to change the defaults via REST API calls? I
agree that we should plan for that now if we think that will eventually
be needed, but I'm not seeing why it would be needed.
The REST API already allows people to cha
On 12/16/2016 05:03 PM, Jay Pipes wrote:
> On 12/16/2016 04:36 PM, Matt Riedemann wrote:
> > On 12/16/2016 2:20 PM, Jay Pipes wrote:
> >>
> >> For problems with placing data like this as configuration options, see
> >> the hassle we went through in making the allocation_ratio options into
> >> fie
On 12/16/2016 4:00 PM, Jay Pipes wrote:
So, we could do that, we already have the quota_classes table and the
os-quota-class-sets REST API, and as mentioned the only usable thing
that goes in there is overriding global default quota.
Would you suggest we drop the global quota limit configuratio
On 12/16/2016 04:36 PM, Matt Riedemann wrote:
On 12/16/2016 2:20 PM, Jay Pipes wrote:
For problems with placing data like this as configuration options, see
the hassle we went through in making the allocation_ratio options into
fields stored in the DB...
Better long-term to have all this kind
On 12/16/2016 2:20 PM, Jay Pipes wrote:
For problems with placing data like this as configuration options, see
the hassle we went through in making the allocation_ratio options into
fields stored in the DB...
Better long-term to have all this kind of configuration live in a data
store (not a co
On 12/15/2016 09:00 AM, Matt Riedemann wrote:
On 12/15/2016 3:11 AM, Andrey Volkov wrote:
Hi,
I totally agree with Matt than `os-quota-class-sets` is inconsistent.
It has that hardcoded default class can't be changed.
API call is documented neither Nova nor Cinder (has the same API for
quotas).
> We're moving quotas to the API and we're going to stop doing the
> reservation/commit/rollback race dance between API and compute nodes per
> this spec:
>
> https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/cells-count-resources-to-check-quota-in-api.html
It's very nice sp
On 12/15/2016 3:11 AM, Andrey Volkov wrote:
Hi,
I totally agree with Matt than `os-quota-class-sets` is inconsistent.
It has that hardcoded default class can't be changed.
API call is documented neither Nova nor Cinder (has the same API for
quotas).
With defaults in the configuration I have som
n one node, 20 cores quota limit in the other node.
>
> Best Regards
> Chaoyi Huang (joehuang)
>
>
> From: Matt Riedemann [mrie...@linux.vnet.ibm.com]
> Sent: 15 December 2016 10:42
> To: openstack-dev@lists.openstack.org
> Subje
Huang (joehuang)
From: Matt Riedemann [mrie...@linux.vnet.ibm.com]
Sent: 15 December 2016 10:42
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova] Let's kill quota classes (again)
On 7/18/2016 6:36 PM, Sean Dague wrote:
> On
On 7/18/2016 6:36 PM, Sean Dague wrote:
On 07/14/2016 08:07 AM, Kevin L. Mitchell wrote:
The original concept of quota classes was to allow the default quotas
applied to a tenant to be a function of the type of tenant. That is,
say you have a tiered setup, where you have gold-, silver-, and
bro
On 07/14/2016 08:07 AM, Kevin L. Mitchell wrote:
The original concept of quota classes was to allow the default quotas
applied to a tenant to be a function of the type of tenant. That is,
say you have a tiered setup, where you have gold-, silver-, and
bronze-level customers, with gold having lot
The original concept of quota classes was to allow the default quotas
applied to a tenant to be a function of the type of tenant. That is,
say you have a tiered setup, where you have gold-, silver-, and
bronze-level customers, with gold having lots of free quota and bronze
having a small amount of
13 matches
Mail list logo
