On Wed, 24 Oct 2018 12:54:00 -0700, Melanie Witt wrote:
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?
[1] https://review.openstack.org/56901
After I sent this, I realized that I _have_ thought about how to solve
these use cases with unified limits before and commented about it on the
"Count quota based on resource class" spec some months ago.
For preemptible instances, we could leverage registered limits in
keystone [2] (registered limits span across all projects) by creating a
limit with resource_name='preemptible', for example. Then we could
decorate a flavor with quota_resource_name='preemptible' which would
designate a preemptible instance type. Then we use the
quota_resource_name from the flavor to check the quota for the
corresponding registered limit in keystone. This way, preemptible
instances can be assigned their own special quota (probably unlimited).
And for quota by flavor, same concept. I think we could use registered
limits and project limits [3] by creating limits with
resource_name='flavorX', for example. We could decorate flavors with
quota_resource_name='flavorX' and check quota for special quota for flavorX.
Unified limits provide all of the same ability as quota classes, as far
as I can tell. Given that, I think we are OK to deprecate quota classes.
Cheers,
-melanie
[2]
https://developer.openstack.org/api-ref/identity/v3/?expanded=create-registered-limits-detail,create-limits-detail#create-registered-limits
[3]
https://developer.openstack.org/api-ref/identit/v3/?expanded=create-registered-limits-detail,create-limits-detail#create-limits
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
