Bug 1884455
Summary: | Quota is not honored when multiple requests are fired in parallel (or in bulk) | ||
---|---|---|---|
Product: | Red Hat OpenStack | Reporter: | Michele Valsecchi <mvalsecc> |
Component: | openstack-neutron | Assignee: | Rodolfo Alonso <ralonsoh> |
Status: | CLOSED NOTABUG | QA Contact: | Eran Kuris <ekuris> |
Severity: | unspecified | Docs Contact: | |
Priority: | medium | ||
Version: | 13.0 (Queens) | CC: | amuller, chrisw, jlibosva, mvalsecc, ralonsoh, scohen |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-10-09 07:53:19 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Michele Valsecchi
2020-10-02 03:43:38 UTC
Hello Michele: This is a known behavior in OpenStack, not only in Neutron. I'll point you to [1]. The recommendation is to place a rate-limiting solution in front of the API endpoints to reduce (not eliminate) the impact a user can cause by making rapid fire requests, as mentioned with the commented script: $ for i in `seq 1 30`; do openstack floating ip create YYYY & done Neutron in particular "does not enforce quotas in such a way that a quota violation like this could never occur. The extent of the issue will vary greatly by deployment architecture, specifically the number of neutron workers that are deployed. If more workers are deployed, this becomes more probable." [2] It was discussed in the Neutron community the possibility to implement a database locking quota system, using the database engine (isolating transactions bumping the same register storing the used resources). But that implies a negative impact in the performance of the API, increasing the response time. This idea was discarded. Therefore, if the customer wants to limit the impact of parallel requests from the same project/user in the quota limits, a rate-limiting system should be applied [3]. Regards. [1]https://bugs.launchpad.net/neutron/+bug/1862050 [2]https://bugs.launchpad.net/neutron/+bug/1862050/comments/5 [3]https://docs.openstack.org/security-guide/api-endpoints/api-endpoint-configuration-recommendations.html#api-endpoint-rate-limiting Hi Rodolfo, Thanks for the swift and detailed response. Performances was picked over consistency: it makes sense given the OSP architecture. Given the circumstances I think this BZ can be closed. I'll be talking with my Customer regarding the necessity of implementation a rate-limiting system in order to address this issue. Regards. |