<div dir="ltr"><div dir="ltr">so FYI, in case people missing this spec, there is spec from John <a href="https://review.openstack.org/#/c/602201/3/specs/stein/approved/unified-limits-stein.rst@170">https://review.openstack.org/#/c/602201/3/specs/stein/approved/unified-limits-stein.rst@170</a></div><div dir="ltr"><br></div><div>the roadmap of this spec is also saying deprecate the quota-class API.</div></div><br><div class="gmail_quote"><div dir="ltr">melanie witt <<a href="mailto:melwittt@gmail.com">melwittt@gmail.com</a>> 于2018年10月25日周四 上午3:54写道：<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 24 Oct 2018 13:57:05 -0500, Matt Riedemann wrote:<br>
> On 10/24/2018 10:10 AM, Jay Pipes wrote:<br>
>> I'd like to propose deprecating this API and getting rid of this<br>
>> functionality since it conflicts with the new Keystone /limits endpoint,<br>
>> is highly coupled with RAX's turnstile middleware and I can't seem to<br>
>> find anyone who has ever used it. Deprecating this API and functionality<br>
>> would make the transition to a saner quota management system much easier<br>
>> and straightforward.<br>
> I was trying to do this before it was cool:<br>
> <br>
> <a href="https://review.openstack.org/#/c/411035/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/411035/</a><br>
> <br>
> I think it was the Pike PTG in ATL where people said, "meh, let's just<br>
> wait for unified limits from keystone and let this rot on the vine".<br>
> <br>
> I'd be happy to restore and update that spec.<br>
<br>
Yeah, we were thinking the presence of the API and code isn't harming <br>
anything and sometimes we talk about situations where we could use them.<br>
<br>
Quota classes come up occasionally whenever we talk about preemptible <br>
instances. Example: we could create and use a quota class "preemptible" <br>
and decorate preemptible flavors with that quota_class in order to give <br>
them unlimited quota. There's also talk of quota classes in the "Count <br>
quota based on resource class" spec [1] where we could have leveraged <br>
quota classes to create and enforce quota limits per custom resource <br>
class. But I think the consensus there was to hold off on quota by <br>
custom resource class until we migrate to unified limits and oslo.limit.<br>
<br>
So, I think my concern in removing the internal code that is capable of <br>
enforcing quota limit per quota class is the preemptible instance use <br>
case. I don't have my mind wrapped around if/how we could solve it using <br>
unified limits yet.<br>
<br>
And I was just thinking, if we added a project_id column to the <br>
quota_classes table and correspondingly added it to the <br>
os-quota-class-sets API, we could pretty simply implement quota by <br>
flavor, which is a feature operators like Oath need. An operator could <br>
create a quota class limit per project_id and then decorate flavors with <br>
quota_class to enforce them per flavor.<br>
<br>
I recognize that maybe it would be too confusing to solve use cases with <br>
quota classes given that we're going to migrate to united limits. At the <br>
same time, I'm hesitant to close the door on a possibility before we <br>
have some idea about how we'll solve them without quota classes. Has <br>
anyone thought about how we can solve the use cases with unified limits <br>
for things like preemptible instances and quota by flavor?<br>
<br>
Cheers,<br>
-melanie<br>
<br>
[1] <a href="https://review.openstack.org/569011" rel="noreferrer" target="_blank">https://review.openstack.org/569011</a><br>
<br>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>