On Tue, Apr 11, 2017 at 1:21 PM, Matt Riedemann <mriede...@gmail.com> wrote:

> On 4/11/2017 2:52 AM, Alex Xu wrote:
>
>> We talked about remove the quota-class API for multiple times
>> (http://lists.openstack.org/pipermail/openstack-dev/2016-July/099218.html
>> )
>>
>> I guess we can deprecate the entire quota-class API directly.
>>
>>
> I had a spec proposed to deprecate the os-quota-class-sets API [1] but it
> was abandoned since we discussed it at the Pike PTG and decided we would
> just leave it alone until Nova was getting limits information from Keystone
> [2].
>

FWIW - in addition to merging the conceptual document [0], Sean recently
proposed the limits interface [1] for the keystone bits.

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.htm
[1] https://review.openstack.org/#/c/455709/


>
> I think the reason we probably missed this API was because of the really
> roundabout way that the information is provided in the response. It calls
> the quota engine driver [3] to get the class quotas. For the DB driver if
> nothing is overridden then nothing comes back here [4]. And the resources
> in the quota driver have a default property which is based on the config
> options [5]. So we'll return quotas on floating_ips and other proxy
> resources simply because of how abstract this all is.
>
> To fix it, the os-quota-class-sets API would have to maintain a blacklist
> of resources to exclude from the response, like what we do for limits [6].
>
> So yeah, I guess we'd need a new spec and microversion for this.
>
> [1] https://review.openstack.org/#/c/411035/
> [2] https://review.openstack.org/#/c/440815/
> [3] https://github.com/openstack/nova/blob/15.0.0/nova/api/opens
> tack/compute/quota_classes.py#L67
> [4] https://github.com/openstack/nova/blob/15.0.0/nova/quota.py#L92
> [5] https://github.com/openstack/nova/blob/15.0.0/nova/quota.py#L1069
> [6] https://github.com/openstack/nova/blob/15.0.0/nova/api/opens
> tack/compute/views/limits.py#L20
>
> --
>
> Thanks,
>
> Matt
>
>
> __________________________________________________________________________
> 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

Reply via email to