so FYI, in case people missing this spec, there is spec from John https://review.openstack.org/#/c/602201/3/specs/stein/approved/unified-limits-stein.rst@170
the roadmap of this spec is also saying deprecate the quota-class API. melanie witt <melwi...@gmail.com> 于2018年10月25日周四 上午3:54写道： > 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 > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
