Open Stack

On Thu, 25 Oct 2018 14:00:08 -0400, Jay Pipes wrote:
> On 10/25/2018 01:38 PM, Chris Friesen wrote:
>> On 10/24/2018 9:10 AM, Jay Pipes wrote:
>>> Nova's API has the ability to create "quota classes", which are
>>> basically limits for a set of resource types. There is something
>>> called the "default quota class" which corresponds to the limits in
>>> the CONF.quota section. Quota classes are basically templates of
>>> limits to be applied if the calling project doesn't have any stored
>>> project-specific limits.
>>>
>>> Has anyone ever created a quota class that is different from "default"?
>>
>> The Compute API specifically says:
>>
>> "Only ‘default’ quota class is valid and used to set the default quotas,
>> all other quota class would not be used anywhere."
>>
>> What this API does provide is the ability to set new default quotas for
>> *all* projects at once rather than individually specifying new defaults
>> for each project.
> 
> It's a "defaults template", yes.
> 
> The alternative is, you know, to just set the default values in
> CONF.quota, which is what I said above. Or, if you want project X to
> have different quota limits from those CONF-driven defaults, then set
> the quotas for the project to some different values via the
> os-quota-sets API (or better yet, just use Keystone's /limits API when
> we write the "limits driver" into Nova). The issue is that the
> os-quota-classes API is currently blocking *me* writing that "limits
> driver" in Nova because I don't want to port nova-specific functionality
> (like quota classes) to a limits driver when the Keystone /limits
> endpoint doesn't have that functionality and nobody I know of has ever
> used it.

When you say it's blocking you from writing the "limits driver" in nova, 
are you saying you're picking up John's unified limits spec [1]? It's 
been in -W mode and hasn't been updated in 4 weeks. In the spec, 
migration from quota classes => registered limits and deprecation of the 
existing quota API and quota classes is described.

Cheers,
-melanie

[1] https://review.openstack.org/602201