Open Stack

Hi,

Basically we should kill quota classes.

It required out of tree stuff that was never implemented, AFAIK.

When I checked with Kevin about this, my memory says the idea was out
of tree authorization plugin would populate context.quota_class with
something like "i_have_big_credit_limit" or
"i_have_prepaid_loads_limit", and if blank fall back to the default. I
don't believe anyone ever used that system. Gives you like groups of
pre-defined quota limits, rather than per project overrides.

Either way, it should die, and now its keystone's problem.
I subscribe to the idea that downstream operational scripting is the
currently preferred solution.

Thanks,
johnthetubaguy

PS
Sorry been busy on SKA architecture last month or so, slowing getting
back up to speed.
On Fri, 26 Oct 2018 at 14:55, Jay Pipes <jaypipes at gmail.com> wrote:
>
> On 10/25/2018 02:44 PM, melanie witt wrote:
> > 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
>
> Actually, I wasn't familiar with John's spec. I'll review it today.
>
> I was referring to my own attempts to clean up the quota system and
> remove all the limits-related methods from the QuotaDriver class...
>
> Best,
> -jay
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev