Reviewed: https://review.openstack.org/408143 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=3ffe006743b33f48bca6fce541e0a8f64f844fb7 Submitter: Jenkins Branch: master
commit 3ffe006743b33f48bca6fce541e0a8f64f844fb7 Author: Kevin Benton <[email protected]> Date: Mon Jan 9 05:02:42 2017 -0800 Switch to 'subquery' for 1-M relationships This switches to the use of subqueries for 1-m relationships which will result in a higher constant query factor but will eliminate the potential for cross-product explosions. Closes-Bug: #1649317 Change-Id: I6952c48236153a8e2f2f155375b70573ddc2cf0f ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1649317 Title: Combinatorial blow-up with the Alchemy strategy lazy='joined' Status in neutron: Fix Released Bug description: A regular tenant can create objects that will require a lot of time to enumerate because of the strategy used by the ORM to build back the objects from the different tables in the database. The script attached can be used to reproduce the problem. It creates a network with several subnetworks (with several routes and DNS servers), several tags, several RBAC policies but it does not exceed any typical quota. Because the network is retrieved at each stage it is modified, it is hard to run this script until its end in a typical setup. Using the strategy lazy='joined' means that a single request is performed to retrieve an object and all its parts that may be expressed in several tables. For example when one asks for the network list, a complex query will be issued that also retrieves subnets, subnetpools, dns agents, etc. The exact query is visible at http://paste.openstack.org/show/592120/ Unfortunately using the strategy lazy=joined has another impact when the relation between the parent object and the sub-object has a ?-n arity. Rather than giving back exactly the row needed, the single query builds a kind of cross-product of the answers sharing the join keys. For example if we have a network with 4 tags and 4 subnetworks, we will have at least 16 rows for each combination of tags and subnetworks. Other fields like rbac rules, special routes, dns servers can amplify the problem. It is not clear if the heavy usage of the database server and neutron server could lead to a real denial of service for other users. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1649317/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
