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:


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?


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

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to