Open Stack

On Wed, 24 Oct 2018 13:57:05 -0500, Matt Riedemann wrote:
> On 10/24/2018 10:10 AM, Jay Pipes wrote:
>> I'd like to propose deprecating this API and getting rid of this
>> functionality since it conflicts with the new Keystone /limits endpoint,
>> is highly coupled with RAX's turnstile middleware and I can't seem to
>> find anyone who has ever used it. Deprecating this API and functionality
>> would make the transition to a saner quota management system much easier
>> and straightforward.
> I was trying to do this before it was cool:
> 
> https://review.openstack.org/#/c/411035/
> 
> I think it was the Pike PTG in ATL where people said, "meh, let's just
> wait for unified limits from keystone and let this rot on the vine".
> 
> I'd be happy to restore and update that spec.

Yeah, we were thinking the presence of the API and code isn't harming 
anything and sometimes we talk about situations where we could use them.

Quota classes come up occasionally whenever we talk about preemptible 
instances. Example: we could create and use a quota class "preemptible" 
and decorate preemptible flavors with that quota_class in order to give 
them unlimited quota. There's also talk of quota classes in the "Count 
quota based on resource class" spec [1] where we could have leveraged 
quota classes to create and enforce quota limits per custom resource 
class. But I think the consensus there was to hold off on quota by 
custom resource class until we migrate to unified limits and oslo.limit.

So, I think my concern in removing the internal code that is capable of 
enforcing quota limit per quota class is the preemptible instance use 
case. I don't have my mind wrapped around if/how we could solve it using 
unified limits yet.

And I was just thinking, if we added a project_id column to the 
quota_classes table and correspondingly added it to the 
os-quota-class-sets API, we could pretty simply implement quota by 
flavor, which is a feature operators like Oath need. An operator could 
create a quota class limit per project_id and then decorate flavors with 
quota_class to enforce them per flavor.

I recognize that maybe it would be too confusing to solve use cases with 
quota classes given that we're going to migrate to united limits. At the 
same time, I'm hesitant to close the door on a possibility before we 
have some idea about how we'll solve them without quota classes. Has 
anyone thought about how we can solve the use cases with unified limits 
for things like preemptible instances and quota by flavor?

Cheers,
-melanie

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