Open Stack

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